[인증/보안] HTTPS
HTTPS (HTTP + Secure)
앞서 배운 HTTP는 사용자를 식별하고 인증하는 것을 도와주는 역할을 가진 프로토콜임을 배웠다. 하지만 이 방법은 우호적인 관계가 형성되어 있는 커뮤니티에서는 잘 동작하지만 적대행위가 일어날 가능성이 있는 커뮤니티에서 중요한 트랜잭션을 보호하기에는 부족하다. 이를 보호하기 위해서는 디지털 암호화 기술을 결합한 HTTPS라는 기술이 필요하다.
HTTPS를 사용할 때, 모든 HTTP 요청과 응답 데이터는 네트워크로 보내지기 전에 암호화된다. HTTPS는 HTTP의 하부에 전송 레벨 암호 보안 계층을 제공함으로써 동작하는데 이 보안 계층은 안전 소켓 계층(SSL, Secure Sockets Layer) 혹은 그를 계승한 전송 계층 보안(TLS, Transport Layer Security)을 이용해 구현한다.
HTTPS 흐름
- 클라이언트가 Client Hello 메시지를 송신하면서 SSL 통신을 시작합니다. 메시지에는 클라이언트가 제공하는 SSL 버전을 지정하고, 암호 스위트(Cipher Suite)로 불리는 리스트(사용하는 암호화 알고리즘이나 키 사이즈 등)이 포함되어 있습니다.
- 서버가 SSL 통신이 가능한 경우에는 Server Hello 메시지로 응답합니다. 클라이언트와 같이 SSL 버전과 암호 스위트를 포합합니다. 서버의 암호 스위스트 내용은 클라이언트에서 받은 암호 스위트의 내용에서 선택된 것입니다.
- 서버가 Ceriticate 메시지를 송신합니다. 메시지에는 공개키 증명서가 포함되어 있습니다.
- 서버가 Server Hello Done 메시지를 송신하여 최초의 SSL 네고시사에션 부분이 끝났음을 통지합니다.
- SSL의 최초 네고세이션이 종료되면 클라이언트가 Client Key Exchange 메시지로 응답합니다. 메시지에는 통신을 암호화하는데 사용하는
Pre-Master secret이 포함되어 있습니다. 이 메시지는 (3)의 공개키 증명서에서 꺼낸 공갸키로 암호화되었습니다.- 클라이언트는 Chahne Cipher Spec 메시지를 송신합니다. 이 메시지는 이 메시지 이후의 통신은 암호키를 생성해서 진행한다는것을 나타내고 있습니다.
- 클라이언트의 Finished 메시지를 송신합니다. 이 메시지는 접속 전체의 체크 값을 포함하고 있습니다. 네고시에이션이 성공했는지 어떤지는 서버가 이 메시지를 올바르게 복호화를할 수 있는지 아닌지가 결정합니다.
- 서버도 마찬가지로 Change Cipher Spec 메시지를 송신합니다.
- 서버에도 마찬가지로 Finished 메시지를 송신합니다.
- 서버와 클라이언트의 Finished 메시지 교환이 완려되면 SSL에 의해 접속은 확립됩니다. 이제부터 애플리케이션 계층의 프로토콜에 의해 통신 입니다. 즉 HTTP 리퀘스트를 송신합니다.
- 애플리케이션 계층의 프로토콜에 의한 통신입니다. 즉 HTTP 리스폰스를 송신합니다.
- 마지막에 클라이언트가 접속을 끊습니다. 접속을 끊을 경우
close_notify메시지를 송신합니다. 그림에서는 생략되었지만 그 후에는 TCP FIN 메시지를 보내 TCP 송신을 종료합니다.
HTTP vs HTTPS 차이
HTTPS 프로토콜의 특징 중 하나는 메시지가 암호화 되어 있어 중간에 가로챌 수도 없고 가로채더라도 암호화된 메시지를 읽을 수 없다. Wireshark라는 오픈소스 패킷 분석 프로그램을 이용해 확인해보자.
기존에 배운 HTTP 프로토콜은 요청과 응답에 암호화가 적용되지 않아 내용이 그대로 노출되는것이 확인된다.
반면 HTTPS 프로토콜은 데이터를 암호화하여 전송하기 때문에 중간에 요청과 응답을 탈취하더라도 정확한 키로 복호화하기 전까지는 내용을 알아볼 수 없다.
암호화
암호화 방식에도 여러종류가 있지만 크게 대칭키 암호화 방식과 비대칭키 암호화 방식을 알아보자.
대칭키 암호화 방식 : 인코딩과 디코딩에 같은 키를 사용하는 암호화 방식
비대칭키 암호와 방식 : 인코딩과 디코딩에 다른 키를 사용하는 암호화 방식
- 공개 키 - 메시지를 암호화 하는데 사용
- 비공개 키(개인키) - 암호화 된 메시지를 해독하는데 사용