HTTPS
HTTP 프로토콜은 전송 정보가 암호회되지 않는 문제점을 가지고 있어서 클라이언트와 서버가 데이터를 주고 받을 때 해커의 공격으로부터 탈취당하기가 쉽다.
이러한 보안상의 문제점을 극복하기 위해 나온것이 SSL(보안 소켓 계층)을 사용한 HTTPS(HyperText Transfer Protocol Secure)인데 주고받는 메세지와 헤더를 모두 암호화한다.
SSL/TSL
SSL은 Secure Sockets Layer의 약자로 웹 서버와 웹 브라우저간의 보안을 위해 만든 프로토콜이다.
대칭키 방식과 공개키 방식을 혼합해서 사용한다.
대칭키와 공개키 방법을 알아보자
대칭키
클라이언트가 비밀키를 가지고 평문을 암호화해서 서버로 보내면 서버에서 클라이언트와 동일한 비밀키를 가지고 암호문을 복호화해 해독하는 방식
대칭키는 암호화/복호화가 쉽다는 장점을 가지고 있고 암호문을 전송하기 때문에 해커가 도중에 탈취해도 해당 정보를 알아볼 수 없다는 장점을 가지고 있다. 하지만 서버와 클라이언트가 동일한 키를 가지고 있기 위해서는 둘 중 한 곳에서 키를 전송해준 다음 암호화/복호화를 진행해야한다.
이 키를 전송하는 과정에서 해커가 키를 가져가버리면 대칭키 암호화 방식은 말짱도로묵이되어버리는 단점이 있다.
공개키
평문 + 공개키 = 암호문, 암호문 + 비공개키 = 평문 으로만 암호/복호화가 가능한 방식
클라이언트에서 평문을 공개키로 암호화해서 서버에 전달하면 서버는 비공개키를 가지고 있고 해독한다. 이 암호화 방식은 해커가 도중에 암호문을 가로채도 비밀키를 들고 있지 않으면 평문을 해독할 수 없기때문에 대칭키보다 보안적인 부분이서 이점이 있지만 암호화 연산 시간이 느리다는 단점도 가지고 있다.
공개키와 대칭키의 서로의 장/단점을 보완하기 위해서 SSL은 이 둘을 혼합한 방식을 사용한다.
HTTPS 통신과정
HTTPS는 HTTP와는 다르게 통신전에 TSL handshake라는 과정을 거치는데 TCP 3-way handshake와는 별도의 과정이다.
- 클라이언트가 client hello를 보낸다. 이때 임의의 난수와 각종 정보들을 같이 실어서 보낸다.
- server hello로 클라이언트에게 응답한다. 이때 서버의 공개키, 서버 난수, 각종 정보가 담긴 담긴 인증서를 보낸다. 인증서 또한 제 3의 인증기관(CA)의 비밀키로 암호화되어있다.
- 클라이언트는 받은 인증서를 CA에서 받은 공개키로 복호화해서 유효한 인증서인지 확인한다. 이 때 거짓된 인증서라면 경고를 보낸다.
- 인증서에 담긴 1과 2에서 생성한 난수를 적절히 조합해 대칭키로 등록한 뒤 마찬가지로 인증서에 담겨있던 서버의 공개키로 암호화하고 서버로 전송한다.
- 해당 난수 조합을 서버의 비밀키로 복호화하고 대칭키로 등록한다.
- 악수를 종료하고 4,5에서 만든 대칭키로 암호화 복호화하며 통신한다.
https://ichi.pro/ko/amhohwa-jeongbo-boan-gisul-234313939662355
https://parksb.github.io/article/24.html