HTTPS 목적
클라이언트와 서버가 1.서로 신뢰하며 2.안전하게 정보를 교환 한다.
의사소통이 이루어지기 이전에 우리는 상대방이 신뢰할 수 있는 사람인지를 서로 확인할 필요가 있다. 네트워크 상에서 서버와 클라이언트의 데이터 교환도 마찬가지이다. HTTPS 에서는 인증서를 통해 이러한 신뢰 문제를 해결한다.
신뢰 문제가 해결된 이후에도 내용을 다른 사람이 볼 수 없는 상태로 의사소통을 해야하는 문제가 남는다. 이 문제는 비대칭 암호화 기술에 공통키를 혼합하여 해결한다.
아래 과정은 TLS 프로토콜의 표준 스펙 중 handshake 이 어떻게 일어나는지를 보여준다. Certificate 와 key exchange 를 통해 위에 제시한 두가지 문제를 어떻게 해결했는지 대략적으로 알 수 있다.
문제 1. 어떻게 해야 서로 믿을까?
나는 내가 믿을 만한 사람인걸 증명하는 인증서가 있어. 이게 찐인지 확인해봐. 그럼 나를 믿을 수 있겠지?
서버가 보낸 인증서를 어떻게 신뢰할 수 있을까?
rfc2459
A certificate user should review the certificate policy generated by
the certification authority (CA) before relying on the authentication
or non-repudiation services associated with the public key in a
particular certificate.
Users of a public key shall be confident that the associated private
key is owned by the correct remote subject (person or system) with
which an encryption or digital signature mechanism will be used.
This confidence is obtained through the use of public key
certificates, which are data structures that bind public key values
to subjects. The binding is asserted by having a trusted CA
digitally sign each certificate.
인증기관이 발행한 인증서에는 공개키가 함께 들어있다. 해당 공개키를 통해 디지털 서명을 검증해서 해당 인증 기관이 정확한 기관인지를 확인한다. 디지털 서명에 대한 간단한 모형은 아래와 같다.
디지털 서명
Alice 는 자신의 개인키로 Hello Bob 문서에 서명했다. Bob 은 이 Hello Bob 문서가 찐인지 확인하기 위해서 Alice 의 public key 를 이용해 검증한다. 찐인지 확인하면 문서의 내용을 신뢰한다.
