HTTP/HTTPS

HTTP란?

• HyperText Transfer Protocol의 약자로 하이퍼텍스트를 전송하기 위해 사용되는 통신 규약.
• 인터넷에서 HTML과 같은 문서를 사용자 컴퓨터에 설치된 웹 브라우저가 웹 서버에 요청할 때의 규칙.
• http 서버는 기본 포트인 80번 포트에서 서비스 대기 중이며, 클라이언트가 TCP 80포트를 사용해 연결하면 서버는 요청에 응답하면서 자료를 전송한다.
• 웹 상에서 정보를 주고받을 수 있는 통신 규약. 주로 html 문서를 주고 받으며 TCP와 UDP를 사용한다.
• http는 정보를 텍스트로 주고 받기 때문에 네트워크에서 전송 신호를 인터셉트하는 경우, 데이터 유출이 발생할 수 있다. 이러한 보안 취약점을 해결하기 위한 프로토콜이 HTTP에 Secure Socket을 추가한 HTTPS이다.

HTTPS란?

• HyperText Transfer Protocol over Secure Socket Layer
• 기본 골격이나 사용 목적은 HTTP와 거의 동일하지만, 데이터를 주고 받는 과정에 보안 요소가 추가되었다.
• https를 사용하면 서버와 클라이언트 사이의 모든 통신 내용이 암호화 된다.
• http의 body를 암호화 한다.
• http는 페이지를 암호화한 키가 그 페이지를 보는 특정 사용자에게만 알려지도록 한다. HTTPS는 SSL이나 TLS(Transport Layer Security. 과거 SSL에서 이름이 변경된 것) 프로토콜을 통해 세션 데이터를 암호화하며, 기본 TCP/IP 포트는 443이고 SSL 프로토콜 위에서 HTTPS 프로토콜이 동작한다.
• SSL/TLS는 응용계층과 전송계층 사이에서 동작하는 독립적인 프로토콜

암호화 방식 - SSL의 동작 방식

1) 비대칭키(공개키)

• A키로 암호화 하면 B키로 복호화 할 수 있다.
• B키로 암호화 하면 A키로 복호화 할 수 있다.
• 둘 중 하나를 비공개키 혹은 개인키라고 부르며, 이는 공개되지 않는다.
• 나머지 하나를 공개키라고 부르고 타인에게 제공한다.

동작 과정

1. 서버는 공개키와 개인키를 만들고, 신뢰할 수 있는 인증기관(CA)에 자신의 정보와 공개키를 관리해달라고 계약한다.
2. 계약을 완료한 인증기관은 기관만의 공개키와 개인키가 있따. 인증기관은 사이트가 제출된 데이터를 검증하고, 인증 기관의 개인키로 사이트에서 제출한 정보를 암호화해서 인증서를 만들어 제공한다. 사이트는 인증서를 가진다.
3. 인증 기관은 웹 브라우저에게 자신의 공개키를 제공한다.

• 공개키 암호화: 개인키로만 복호화 가능 -> 데이터를 확실하게 암호화할 수 있다.
• 개인키 암호화: 공개키는 공개되어 있으므로 사용자 인증을 위해 사용된다.

2) 대칭 키 암호화 방식

• 공개 키의 느린 단점을 보완한 방식.
• 동일한 키로 암호화, 복호화가 가능하다.
• 대칭 키는 매번 랜덤으로 생성되어 누출되어도 다음에 사용할 때는 다른 키가 사용되기 때문에 안전하다.
• 공개 키보다 빠르게 통신할 수 있고 암복호화에 드는 비용이 적다.
• 하나의 키로 암복호화 하기 때문에 해당 키가 노출되면 보안상 치명적이다.

동작 과정

1. 사용자가 사이트에 접속하면 서버는 자신의 인증서를 웹 브라우저에게 보낸다. (ex. 웹 브라우저가 index.html을 요청하면, 서버의 정보를 인증 기관의 개인키로 암호화한 인증서를 받게 된다.)
2. 웹 브라우저는 미리 알고 있던 인증기관의 공개키로 인증서를 해독하여 검증해 사이트의 정보와 서버의 공개키를 알 수 있게 된다.
3. 이렇게 얻은 서버의 공개키로 대칭키를 암호화해서 다시 사이트에 보낸다.
4. 사이트는 개인키로 암호문을 해독하여 대칭키를 얻고, 이제 대칭키로 데이터를 주고 받는다.

HTTPS에서는 대칭키와 비대칭키를 모두 사용한다. 서버와 클라이언트가 주고 받는 모든 메시지를 비대칭키로 암호화하면 오버헤드가 발생할 수 있음.
서버와 클라이언트가 최초 1회로 대칭키를 공유하기 위해 비대칭키 암호화를 사용하고 이후에는 대칭키 암호화를 사용한다.
1. 클라이언트가 서버로 최초 연결 시도
2. 서버는 인증서를 브라우저에게 넘겨줌
3. 클라이언트(브라우저)는 인증서의 유효성 검사. 세션키 발급
4. 브라우저는 세션키를 보관하며 서버의 공개키로 세션키를 암호화해 서버로 전송
5. 서버는 개인키로 암호화된 세션키를 복호화해 세션키를 얻음
6. 클라이언트와 서버가 동일 세션키를 공유하므로 데이터 전달 시 세션키로 암호화 복호화를 진행

SSL의 플로우

• 클라이언트는 응용 계층의 http 프로토콜에서 사용자의 데이터를 받고 전송 계층으로 캡슐화되기 이전에 SSL 프로토콜에 의해 사용자의 데이터가 암호화 된다.
• 서버에서는 전송 계층에서 세그먼트를 받아 SSL 계층에서 데이터를 복호화하여 응용계층으로 보낸다.CA란?
  Certification Authority는 공개키와 공개 DNS명(ex. www.example.com) 연결을 보장하는 기관다. 클라이언트가 www.example.com의 공개키가 해당 공개키인지 알 수 있게 해준다. CA는 자신만의 암호화 키로 해당 공개키가 특정 사이트의 공개키라는 것을 보장한다. 이 서명은 계산적으로 위조할 가능성이 없다.
  즉, 접속한 서버가 클라이언트가 의도한 서버가 맞는지 보장.

SSL 인증서의 정보
- 서비스의 정보(인증서를 발급한 CA, 서비스의 도메인 등)
- 서버 측 공개키(공개키 내용, 암호화 방식)

SSL 인증서의 역할
- 클라이언트가 접속한 서버가 신뢰할 수 있는 서버임을 보장
- SSL 통신에 사용한 공개키를 클라이언트에게 제공

브라우저가 CA의 공개키를 어떻게 알까?
웹 브라우저는 이미 브라우저가 자동으로 신뢰하는 CA 인증서 집합 사전이 구성되어 있다.
웹 브라우저는 모든 주요 인증 기관의 공개키와 함께 설치된다. 이 공개키를 사용하여 웹 서버의 인증서가 실제로 신뢰할 수 있는 인증 기관에 의해 서명되었는지 확인한다.
즉, 웹 브라우저는 내부적으로 CA 리스트와 함께 공개키가 포함된 인증서를 갖는다.
이러한 SSL 방식을 적용하려면 인증서를 발급받아 서버에 적용시켜야 한다. 인증서는 사용자가 접속한 서버가 우리가 의도한 서버가 맞는지를 보장하는 역할을 한다. 인증서를 발급하는 기관은 CA(Certificate Authority)라고 부른다.

HandShake Protocol

HTTPS의 장점

• 웹 사이트의 무결성을 보호해준다. 웹 사이트와 사용자 브라우저 사이의 통신을 침입자가 건드리지 못하게 한다.
• 사용자의 정보를 웹 서버와 주고 받아야하는 경우라면 http는 정보 유출의 위험성을 갖는다. https는 웹사이트와 사용자 사이의 통신을 침입자가 수신하는 것을 방지해 보안을 강화시켜준다.

HTTPS의 단점

• 모든 사이트에서 텍스트를 암호화해서 주고 받으면 과부하가 걸려 속도가 느려질 수 있다. 중요한 사이트는 https로 관리하고, 그렇지 않다면 http를 사용한다.

참고:
HTTPS란?
HTTP/HTTPS 차이점