HTTP와 HTTPS

HTTP는 서버와 클라이언트 간에 통신을 주고받는 프로토콜을 말한다. 이 프로토콜 방식은 주고받는 데이터가 암호화되지 않기 때문에 보안 문제가 발생할 수 있다. 따라서 HTTPS 프로토콜을 사용하는데 이는 HTTP 프로토콜에 보안 기능을 추가한 것이다. 2014년부터 구글은 웹 전반의 보안을 개선하기 위해 모든 사이트에 HTTPS 방식을 사용할 것을 요구했으며 HTTPS를 사용한 사이트에는 가산점을 주어 사용자들에게 잘 노출되도록 했고, HTTPS를 사용하지 않을 경우 '안전하지 않음'의 경고 문구를 보내며 사용자들이 접속하지 않게끔 하였다. 그렇다고 HTTPS가 모든 보안 문제를 해결하는 것은 아니다. 최소한의 요건만 갖춘 것이다.

---

HTTP

Server와 Client 간에 데이터를 주고받는 통신 프로토콜로 HTTP /1 버전에서는 3 Way Handshake과정을 통해 연결 요청 및 확인을 하고 데이터를 주고받는다.(/2 버전에서는 HTTP Header를 간소화하고, /3 버전에서는 UDP 프로토콜 기반의 QUIC 프로토콜을 사용) HTTP는 80번 포트를 사용하기 때문에 클라이언트는 80번 포트로 요청을 보낸다.

※프로토콜 : 컴퓨터 내부에서, 또는 컴퓨터 사이에서 데이터의 교환 방식을 정의하는 규칙 체계

 

Request Header 정보[참고]

GET /example.html HTTP/1.1  →Method / 경로 / 프로토콜 버전
Accept : 서버에게 요청 받을 때 바라는 특정 타입 정보  ex) text/html, application/xhtml+xml
Cache-Control : 캐시 정보 입력 ex) no-cache, no-store, must-revalidate
Connection :  현재의 전송이 완료된 후 네트워크의 접속을 유지할지 말지를 제어 ex) keep-alive, close
Host : 서버의 도메인명과 서버가 리스닝하는 TCP 포트 ex) Host: <host>:<port>
Referer : 현재 요청을 보낸 페이지에 대한 주소로 분석, 로깅, 캐싱 최적화에 사용됨
Authorization : 서버에 인가된 사용자임을 증명하는 자격정보, 없으면 401 Unauthorized 에러를 던짐
                         ex) Authorization: <type> <credentials>

Response Header 정보[참고]

HTTP/1.1 200 OK
Date :
Content-Type : 리소스의 미디어 타입을 나타내기 위해 사용 ex) Content-Type: text/html; charset=utf-8
Access-Control-Allow-Origin : 이 응답이 주어진 origin으로부터의 요청 코드와 공유될 수 있는지
                                                ex) Access-Control-Allow-Origin: *
                                                ex) Access-Control-Allow-Origin: https://developer.mozilla.org
Allow : 어떤 요청 메소드를 사용할 수 있는지 알리기 위해 사용 ex) Allow: GET, POST, HEAD

 

HTTPS

HTTP 프로토콜에 보안 기능(암호화)을 추가하여 데이터의 무결성과 기밀성을 유지한다. 따라서 데이터는 SSL이나 TLS 프로토콜을 통해 데이터를 암호화하는 과정을 거쳐 전송된다. HTTPS는 443 포트를 사용한다.

 

• 클라이언트와 서버 간 주고받는 데이터는 암호화가 되어있어 제 3자가 볼 수 없다.
• HTTPS 프로토콜을 사용한 서버는 믿을만한 사이트이다.

SSL/TLS

Secure Socket Layer로 암호화 기반 인터넷 보안 프로토콜이다. 현재는 SSL에서 발전한 TLS(Transport Layer Security) 프로토콜이 사용되고 있다. SSL을 Netscape에서 먼저 개발하였지만, 이후 업데이트를 IETF(Internet Engineering Task Force)에서 담당하고 Netscape에서 관여하지 않게되면서 이름이 변경되었다. TCP/UDP 프로토콜에 TLS 인증방식을 추가하였다. 두 인터넷 기기간에 HandShake과정을 거치며 서로를 인증하고, 무결성을 보장하기 때문에 안전한지 확인할 수 있다.

 

특징 [참고]

• 암호화 : 제3자로부터 전송되는 데이터를 숨김
• 인증 : 정보를 교환하는 당사자가 요청된 당사자임을 보장
• 무결성 : 데이터가 위조되거나 변조되지 않았는지 확인하는 알고리즘이 있어 확인이 가능

CA의 역할

• SSL은 CA(Certificate Authority)에서 관리되며 CA는 디지털 서명을 해주는 인증기관
• CA는 민간기업이나 신뢰할 수 있는 검증된 기간만이 운영 가능
• HTTPS를 적용하려는 기업의 요청으로 공개키를 저장할 수 있는 인증서 발급 후 기업에 전달
• 인증서에는 소유자(CA)의 이름, 요청한 기업 측의 공개키, 유효기간, ID를 기반으로 한 값들이  CA기관의 개인 키로 암호화되어 들어있음
• 브라우저는 CA 기관의 공개 키를 미리 가지고 있어 서버에서 인증서를 보내온다면 CA의 공개키로 복호화하여 확인 가능
• 만약 인증된 기관이 아닐 경우 주소창에 자물쇠 잠금모양의 마크를 볼 수 있다.

신뢰할 수 있는 CA 기관<구글 검색>

 

 

대칭키와 비대칭키

암호키를 이용하여 데이터를 암호화/복호화 하는 방식

대칭키 암호화

• 수신자와 송신자가 동일한 키를 가지고 있어 암호화, 복호화할 수 있다.
• 공개 키와 비교하여 연산속도가 빠르다.
• 동일한 키를 수신자와 송신자 모두 공유해야하는데 누군가가 가로챌 수 있어 보안에 취약하다.
• 대칭 키 알고리즘 AES, SEED, ARIA, DES 등이 있다.

비대칭키 암호화(공개키)

• 암호화와 복호화 하는 과정에서 공개 키와 개인 키가 따로 사용되며 공개 키로 암호화된 데이터는 공개 키로 복호화할 수 없다.
• 공개 키 : 모두에게 공개 가능한 키로 서버가 클라이언트에게 제공하여 클라이언트는 암호화해서 서버에 데이터를 보낸다.
• 개인 키 : 자신만이 가지고 있는(알고 있는) 키로 클라이언트가 공개 키로 암호화하여 보낸 데이터를 개인 키로만 복호화 할 수 있다. 개인 키는 서버만이 가지고 있기 때문에 외부에 노출될 위험이 적다. 
• 매번 서로 다른 키(알고리즘)로 암호화, 복호화 과정을 거치기 때문에 대칭 키에 비해 연산속도가 느리다.
• 비대칭 키 알고리즘으로 RSA 등이 있다.

HTTPS 동작 방식

HTTPS에서는 대칭 키와 비대칭 키 방식을 모두 사용한다.

 

1. SSL HandShake 과정

1. Client Hello
   • 클라이언트가 생성한 랜덤데이터를 서버에 전달
   • 클라이언트가 지원하는 암호화 방식을 서버에 전달(다 전달하면 서버에서 선택)
   • 이전에 연결을 했다면 세션 ID를 전달
2. Server Hello
   • 서버에서 생성한 랜덤데이터를 클라이언트에게 전달
   • 클라이언트가 보낸 암호화 방법 중 하나를 선택한 암호화 방식 전달
   • 서버의 공개 키가 담긴 SSL 인증서 전달
3. 서버의 인증서 확인
   • 브라우저가 가지고 있는 CA 리스트에 해당하는 인증서인지 확인 후 있다면 CA의 공개키로 복호화
   • 해당 인증서에는 서버의 공개키를 포함하고 있음
   • 해당 인증서가 CA 리스트에 없다면 경고메시지 출력
4. PremasterSecret 생성
   • 서버와 주고 받은 임의의 데이터를 조합해 Premaster Secret 키 생성
   • premaster Secret 키를 서버의 공개키로 암호화해서 전달
5. Master Secret 생성 후 Session Key 생성
   • 클라이언트 측으로 부터 받은 premaster Secret 키를 서버의 개인키로 복호화
   • Premaster Secret 값으로 Master Secret 키 생성 후 Session Key 생성
   • 앞으로 Session Key는 서버와 클라이언트에게 공유되어 대칭키 암호화 방식으로 사용됨
6.  Handshake 종료 후 Session Key로 통신

 

2. 세션

실제로 서버와 클라이언트 간 Session Key를 활용한 대칭 키 방식으로 데이터를 주고 받음

 

3. 세션 종료

데이터 전송을 마치고 연결 종료를 하며 Session Key 폐기

---

참고하면 좋은 사이트

[HTTP-Header] HTTP 헤더란? 그리고 Header의 종류

HTTP 프로토콜 1.0 vs 1.1 vs 2.0 비교

HTTP Headers for Dummies

대칭키 암호 시스템

HTTPS와 SSL 인증서 - 생활코딩

154. [Security] SSL과 인증서 구조 이해하기 : CA (Certificate Authority) 를 중심으로

HTTPS를 위한 SSL/TLS 핸드 셰이크 작동원리

SSL이란 무엇인가