만일 http 프로토콜을 사용한 통신으로 id와 pw를 전송한다면, 그건 이미 다른 해커의 손에 넘어갔다고 생각하자.
Http 프로토콜은 보안을 전혀 고려하지 않고 만들어진 프로토콜이기에 이를 보완하고 암호화된 통신을 위해 4계층에 tcp위에 동작하는 추가적인 TLS 프로토콜을 만들어 사용하게 되었다.
TLS
CIA를 보장하는 암호화 통신 프로토콜. 
- Cipher negotiation
각자 구현된 암호화 spec을 공유하고 암호화 알고리즘을 선택 - Authentication
각자가 생각한 대상이 맞는지 상호 인증 - Key Exchange
암호화 통신을 위한 대칭 key를 교환
3가지의 단계로 이루어져 있는 프로토콜이다. 물론, tcp위에서 동작하므로 tcp 연결이 설정되었다 가정한다.
대략적인 프로토콜의 개요도이다.
- CipherSuite negotiation
클라이언트가 서버에게 자신이 가능한 암호화 프로토콜의 리스트를 건네고, 서버는 그 중 하나를 골라서 응답한다.
위의 예시로 생각해보자면, ECDHE로 키 교환을 진행할 것이며 ECDSA로 상호에 대한 인증을 실시, AES128로 암호화를 할 것이며 GCM(갈루아 카운터 모드)로 암호화를 실시하고, SHA를 통해 무결성을 체크할 것이라는 뜻이다.
클라이언트 헬로우 과정 에서 클라이언트가 서버에게 보내는 자신에게 구현된 암호화의 종류 list - Authentication
RSA 혹은 ECDSA를 상호를 인증한다. TLS 1.3부터는 RSA가 퇴출되었다. - Key Exchange
RSA 키 교환 혹은 디피-헬먼 키교환으로 키를 교환한다. TLS 1.3부터는 RSA 키 교환이 퇴출 되었다.
RSA 키 교환은 PFS를 보장 불가능 하지만 디피-헬먼 키 교환은 PFS를 보장할 수 있다.
TLS 1.3
구식 알고리즘을 제거하고, 속도를 개선하였다.
기존 Cipher negotiation에서는 모든 조합을 일일히 리스트에 저장했지만, TLS 1.3부터는 알고리즘별로 리스트에 저장하고 조합하는 형태로 바뀌게 되었다. 또한, negotiation과정 중 중간자가 낮은 bit의 암호화 알고리즘을 사용하도록 유도하는 FREAK을 방지할 수 있도록 negotiation 과정 중에서 서명이 추가되었다.
CA&PKI
CA의 인증서를 통해 인증된 서버와의 통신이 가능하다. CA의 인증서 발급의 문제점을 살펴보자
증명서 발급을 소홀히 하는 문제
증명서의 Revoke문제
- CRL을 통해 해결
Revoke된 인증서의 리스트이다. 리스트가 길어지면, 효율이 낮아진다. - OCSP
증명서를 CA에 보내서 유효한지 검사하는 방법
CS 박제