패킷을 잡아서 보면 클라이언트와 서버가 주고받는 모든 데이터를 볼 수 있다.
HTTPS 는 HTTP 통신을 하되 TLS프로토콜에 따라 암호화된 통신을 하는 프로토콜이다. TLS는 HTTP 방식 뿐만아니라 TCP통신을 하는 FTP같은 프로토콜에도 적용될 수 있다.
정보의 송신자와 수신자가 서로 알고있어야하며, 송신자는 이 대칭키를 사용해 암호화를 수신자는 대칭키를 사용해 복호화를 하게된다.
정보의 송신자와 수신자(통신에서는 서버와 클라이언트)만 이 공개키를 알고있어야 하는데, 이 공개키를 통신으로 보낼경우 노출되고, 공개키가 노출되는 순간 더이상 안전하게 암호화 되었다고 볼 수 없다.
대칭키의 약점을 해결하는 방식이다.
공개키 방식에서는 키가 두개 존재 한다.(Public Key, Private Key)
A라는 키를 사용해 암호화 했다면, B라는 키를 사용해 복호화 하여야만 복호화가 가능하다
A의 공개키는 aaaaaa이고, 비밀키는 bbbbbb이다
A의 공개키는 어디서든 볼 수 있게 공개되어있다.
B가 A에게 어떠한 정보를 보낼 때, A의 공개키인 aaaaaa를 사용하여 암호화를 한다.
이와중에 해커인 C가 B가 A에게 보낸 정보를 복호화해서 나쁜짓을 하려고한다.
C는 A의 공개키인 aaaaaa를 사용해 복호화를 했지만 복호화되지 않는다.
B가 A의 공개키인 aaaaaa를 사용해 암호화를 했기때문에, 비밀키인 bbbbbb를 사용해야만 복호화 할 수 있는데,
이 비밀키는 A만 알고 있기 때문에 C는 정보를 가로챌 수 없다.
바로 전에 작성한 A에서 B로의 데이터 전송에서, 이번에는 인증에 사용되는 예시이다.
A는 B에게 비밀키로 암호화된 데이터와 공개키를 전송한다.
이번에도 C가나타나 공개키를 통해 복호화하려고한다.
즉 이 데이터와 공개키를 가진사람은 A가보낸 정보를 모두 복호화 할 수 있다.
그렇기 때문에 여기서 공개키는 암호로써의 역할을 하지 못한다고 볼 수 있다.
하지만 공개키와 짝을이루는 비밀키를 사용한 사람만이 공개키를 통해 복호화할 수 있는 정보를 보낼 수 있기때문에,
이정보가 A가 보낸 정보임을 보장하는 것이다.
이것이 인증서의 원리가 된다.
인증서의 기능은 크게 두가지
1. 클라이언트가 접속한 서버가 신뢰할 수 있는 서버임을 보증
2. SSL 통신에 사용할 공개키 제공
이 역할을 하는 민간기업을 CA라고 부른다. SSL을 통해 암호화된 통신을 제공하려는 서비스는 이 CA에서 인증서를 구입해서 사용하여야 하며, 내부적인 용도나 개발의 용도로 사용할때는 사설 CA, 즉 자기자신이 CA가되는 방법도 존재한다.
각 브라우저는 CA의 리스트와 공개키를 기본적으로 알고있다.
클라이언트가 서버에게 다음과 같은 정보를 전송한다.
서버가 클라이언트에게 다음과 같은 정보를 전송한다.
클라이언트는 서버가 제공한 인증서가 CA에 의해 제공된 것인지 확인하기 위해, 브라우저가 가지고있는 CA의 리스트를 확인한다.
만약 리스트에 없다면 경고, 리스트에 있다면 해당하는 CA의 PublicKey를 사용해 인증서가 복호화되는지 확인한다. 이 과정에서 복호화가 정상적으로 진행된다면 서버는 해당 CA에 의해 인증되었음을 뜻하고, 이 과정에서 서버의 Public Key를 얻을 수 있다.
클라이언트는 1에서 생성한 랜덤값과 2에서 생성한 랜덤값을 조합하여 Pre-master Secret이라는 대칭키를 생성하게 된다. 또한 서버의 공개키를 사용하여 이 Pre-master Secret Key를 암호화 시키고 서버에 전송한다
서버는 PrivateKey를 통해 Pre-master Secret Key를 복호화해내고,
서버와 클라이언트 모두 일련의 과정을 거쳐 Master-Secret이라는 값을 얻어낸다.
Master-Secret은 Session Key값을 생성하고, 생성된 Session-Key는 데이터의 송수신 시에 대칭키 값으로 사용되고, 해당 세션이 만료되면 폐기된다.
공개키 방식이 더 많은 컴퓨터 리소스를 잡아먹기 때문에...