Computer Science/네트워크

HTTP와 HTTPS

부리부리부리부리 2024. 1. 13. 13:33

HTTP

 

HTTP는 HyperText Tranfer Protocol로 WWW상에서 정보를 주고 받는 프로토콜이다.클라이언트인 웹브라우저가 서버에 HTTP를 통해 웹페이지나 이미지 정보를 요청하면 서버는 이 요청에 응답하여 요구하는 정보를 제공하게 된다.결국,HTTP 는웹브라우저(Client)와 서버(Server)간의 웹페이지같은 자원을 주고 받을 때 쓰는 통신 규약이다. http는 텍스트 교환이다. html페이지도 텍스트다. 바이너리 데이터로 되어있는 것도 아니고 단순 텍스트를 주고 받기 때문에 누군가 네트워크에서 신호를 가로채어 본다면 내용이 노출된다.이런 보안상의 문제를 해결해주는 프로토콜이 HTTPS다.

 

HTTPS

 

HTTPS는 인터넷 상에서 정보를 암호화하는 SSL(Secure Socket Layer)프로토콜을 이용하여 웹브라우저(클라이언트)와 서버가 데이터를 주고 받는 통신 규약이다.HTTPS는 http 메세지(text)를 암호화하는 것이다.HTTPS의 S가 Secure Socket, 보안 통신망을 말한다.HTTPS의 암호화 원리를 간단히 알아보면 핵심은공개키 암호화 방식이다.

 

SSL(보안 소켓 계층)은 서버와 브라우저 사이에 안전하게 암호화된 연결을 만들 수 있게 도와주고, 서버와 브라우저가 민감한 정보를 주고 받을 때 해당 정보가 도난당하는 것을 막아준다.

 

HTTP vs HTTPS

 

HTTP와 HTTPS의 차이점은 간단하다. 보안 적용의 유무이다.
보안의 핵심에는 SSL/TLS 프로토콜과 CA 인증 메커니즘에 있다.
HTTP는 SSL/TLS 인증서를 사용하지 않고 HTTPS는 SSL/TLS 인증서를 사용한다.

(여기서 TLS는 SSL의 개선된 버전)

 

"인증서를 사용한다" 라는 말의 의미를 좀 더 알아보자.

 

HTTP는 클라이언트-서버 구조에 사용되는 프로토콜이다.

요청-응답 구조를 가지며 인터넷에서 가장 많이 사용되는 프로토콜인 HTTP.

HTTP의 단점은 "보안이 적용되지 않은 데이터"를 전송한다는 것이다. 상당히 위험하다.

네트워크의 전형적인 공격인 "중간자 공격"에 취약하고 언제든지 데이터가 도청될 수 있는 네트워크 환경에서는 네트워크를 사용하는 내내 위험하다고 볼 수 있다.

 

HTTPS는 HTTP에 TLS 계층을 더한 것이다.

  • TLS은 서버와 브라우저 사이에 안전하게 암호화된 데이터를 전송할 수 있게 해 준다.
  • HTTP는 80 포트를 사용하고 HTTPS는 443번 포트를 사용한다.

암호화 메커니즘을 통해 암호학에서 핵심으로 두는 3가지 보안 기능성을 얻게 된다. (CIA)

 

TLS (Transport Layer Security)

1999년에 SSL의 새 버전으로 도입된다. SSLv3을 기반으로 하며 SSLv3의 개선 버전이다.

SSL이라는 표현이 일반적으로 사용되고 있어서 현재도 보안 인증서를 SSL 인증서라고 부른다.

HTTPS는 웹 사이트를 SSL/TLS 인증서로 보안하는 경우를 의미한다.

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

  • 공개키로 데이터를 암호화하여 공개키 소유자에게 보낸다. 공개키 소유자는 개인키로 복호화한다.

[ 공개키는 데이터를 암호화하는 용도이고, 개인키는 데이터를 복호화하는 용도이다. ]

암호화 절차가 까다롭기에 데이터를 암호화하기보다는 서로의 신원을 확인하거나 특정 데이터( 대칭키 )를 공유하는 용도로 사용한다.

대칭키 암호화 (대칭 암호화)

암호화와 복호화에 같은 "비밀키"를 사용한다.

빠르게 데이터를 암호화/복호화할 수 있으나 상대방이 안전한 사람인지 확인할 방법이 없다.

그래서 비대칭 암호화로 안전한 상대인지 확인하고 이후의 데이터를 대칭키로 암호화/복호화하는 하이브리드 방식으로 진행한다.

SSL/TLS 디지털 인증서 [ CA를 통해 보장받는다. ]

클라이언트와 서버 간의 통신을 공인된 제삼자(CA)가 보증해주는 문서이다. 해당 문서를 통해 서버의 안정성을 보장받을 수 있다. (주소 입력창 HTTPS 프로토콜 쪽에 자물쇠로 확인 가능!)

클라이언트로 하여금 접속하려고 하는 서버가 신뢰할 수 있는 서버인지 확인하는 데 사용한다.

SSL/TLS 디지털 인증서가 적용되어야 구글 검색 엔진에서 가산점을 받을 수 있다.

TCP/IP 세션을 연결하는 3-way handshake 다음으로 보안을 위한 SSL/TLS handshake 과정을 거친다.

송신자와 수신자가 암호화된 데이터를 교환하기 위한 협상과정을 거치는 것이다.

SSL 인증서 전달, 대칭키( 데이터 암호화 복호화에 사용할 비밀키) 전달, 암호화 알고리즘 결정 등이 처리된다.

우측에 시간을 보면 TCP 핸드셰이크 과정보다 TLS 핸드셰이크 과정이 2배 정도 길다는 것을 알 수 있다.

TLS handshake 절차

1. Client Hello [ 사용 가능한 암호화 알고리즘을 전달 ]

ciper suite 정보 여기에 모든 보안 처리가 담겨있다. [ 가장 중요한 suite ]

  1. 세션 아이디 [ 해당 세션을 재사용하기 위함 ]
  2. TLS 프로토콜 버전 [ 호환성 체크 ]
  3. 랜덤 바이트 정보
  4. 사용 가능한 암호화 목록(ciper suite 정보)을 전달한다.

[ 프로토콜, 키 교환 방식, 인증서 검증용, 대칭키를 이용한 블록 암호화 방식, 메시지 인증 등등이 해당된다. ]

2. Server Hello (서버의 응답) [ 클라이언트가 제공한 알고리즘 목록 중 하나 선택 + CA 인증서 전달 ]

클라이언트의 가능한 암호화 목록 중 하나를 선택하여 클라이언트에 응답한다.

Server는 인증 기관(CA)의 개인키(비밀키)로 암호화하여 "서버의 SSL/TLS 인증서"를 Client에 전달한다.

[ 인증서의 경우 CA의 비밀키로 암호화된 상태이다. ]

임의의 난수를 전달한다.

3. Client Certificate 처리 [ 서버의 CA 인증서 확인 + 앞으로 교환할 비밀키 전달 ]

인증서 내부에는 서버가 발행한 공개키가 들어있다.

클라이언트는 서버가 보낸 암호화된 SSL 인증서를 CA의 공개키로 복호화한다.

[ 브라우저는 이 과정을 수월하게 처리하기 위해서 CA들의 정보와 CA가 만든 공개키를 미리 설치해둔다. ]

CA가 만든 인증서인지 확인하기 위해서 CA의 공개키로 암호화된 인증서를 복호화한다.

[ 여기서 실패하면 브라우저 경고를 보낸다. ]

복호화에 성공했다면 해당 인증서는 CA의 개인키로 암호화되었음을 확인하게 되면서 CA의 인증을 받았다는 것을 확인하게 된다.

3 - 1). key Exchange

클라이언트는 대칭 암호화에 사용할 비밀키를 서버의 공개키( CA 개인키로 암호화된 정보를 CA 공개키로 복호화해서 알아낸 정보)로 암호화하여 서버로 전송한다.

이 정보를 premaster secret이라 부른다.

해당 비밀키가 앞으로의 데이터를 암호화하고 복호화에 사용될 것입니다.

4. 서버의 처리 [ 비밀키 확인. SSL/TLS 연결 종료. 이후 데이터 교환 ]

서버는 자신의 공개키로 암호화된 클라이언트가 보낸 premaster secret을 서버의 개인키로 복호화한다.

이로써 클라이언트와 서버는 데이터 암호화 복호화에 사용할 비밀키를 공유하게 된다.

Finished 패킷을 보내면서 SSL Handsake를 종료하고 이후 비밀키를 통해 암호화 복호화 과정을 처리하게 된다.