본 내용은 한양대학교 이석복 교수님의 강의를 참고하여 정리하였습니다. 교재는 Pearson/Addison Wesley에서 출판한 Computer networking : a top-down approach입니다.
SSL (Secure Socket Layer)
- 네트워크 통신에서 메시지 전송을 안전하게 하기 위한 프로토콜
- 예시
* HTTPS
- SSL 필요 이유와 등장
* 보안이 없을 경우, 지나가는 PKT을 가로채서 마음대로 할 수 있다.
* 가장 쉬운 방법은 사용자가 메시지를 암호화해서 socket에 넣어주는 방법
* 사용자가 매번하기 번거롭기 때문에 자동으로 해줄 수 있는 프로토콜 필요하여 SSL 등장
- 동작
0. TCP 연결 이후에 이루어지는 과정입니다.
1. Client는 Server에게 https로 요청을 보냅니다.
2. Server는 공인 인증기관에서 발급한 private key로 암호화된 server의 인증서를 보냅니다. 인증서의 구성은 자신이 누구인지와 server의 public key가 담겨져 있습니다.
3. Client는 공인 인증기관의 public key로 복호화하여 내분에 있던 server의 public key를 얻습니다. Client는 4개의 키로 구성된 master secret key를 생성하고, server의 public key로 암호화하여 보냅니다.
4. Server는 자신의 private key로 메시지를 복호화하고, master secret으로부터 대칭키와 MAC키를 생성합니다. 생성된 key들로 암호화 통신을 합니다.
- Master secret으로 부터 얻는 4개의 key
* Kc : client가 server에게 데이터를 보낼 때 암호화하는 대칭키
* Mc : client가 server에게 데이터를 보낼 때 MAC을 만들기 위해 필요한 키
* Ks : server가 client에게 데이터를 보낼 때 암호화하는 대칭키
* Ms : server가 client에게 데이터를 보낼 때 MAC을 만들기 위해 필요한 키
- MAC (Message Authentication Code)
* MAC은 데이터의 뒤에 붙어서 메시지가 온전하게 도착하게 하는 보안 기능
* 어떻게? MAC에는 아래 나열된 정보들과 MAC key가 함께 해시 함수를 통과했다. 도착지에 도달하면, 호스트는 아래 나열된 정보와 자신이 가진 MAC key를 해시 함수에 넣어서 두 MAC 값을 비교할 것이다. 결국, MAC key가 있어야 메시지를 변경했을 때 호스트를 속일 수 있다. 그런데 MAC key는 구할 수 없다.
* MAC은 일종의 해시 값으로, 위의 Mx키와 메시지 순서, 데이터의 종류, 데이터를 합친 것을 해시 함수에 넣어서 나온 값이다.
+ MAC = H(MACx, sequence||type||data)
* Sequence를 넣는 이유 : 중간에 제3자가 A 패킷과 B 패킷의 payload를 바꾸었다고 가장하자. 목적지 호스트는 바뀐 패킷인지 모르고 application layer로 올려버리면, 이미 내용물은 뒤죽박죽이라서 쓸 수 없다. 이를 방지해야 했다.
* Type을 넣는 이유 : type = 1은 TCP 연결 종료, type = 0은 TCP 연결 중을 의미한다. 중간에 제3자가 의도적으로 type을 바꾸어 TCP 연결을 강제로 끊을 수 있다. 이를 방지해야 했다.
- SSL record protocol
* Data는 조각으로 나뉩니다.
* 여러 header의 정보들(type, seq, etc)과 MAC key를 함께 해시 함수에 넣어 MAC을 만들고 붙입니다.
* 대칭키를 사용하여 data fragement와 MAC을 암호화 합니다.
우리나라 공인인증서 - 우리나라는 신기하게도 개인이 공인인증서를 가지고 있습니다. 즉, 개인이 스스로 증명해야 하는 시스템입니다. 그런데 위에 설명된 과정은 서버가 자신임을 밝히는 시스템입니다. 둘 어떤 것이 더 보안이 좋은지 지식이 부족해서 쓰지 못하겠습니다. 이후 알게 된다면, 업데이트 하겠습니다.
Warning message?
- 간혹, 위와 같은 경고 메시지를 볼 때가 있습니다. 과정을 설명 하자면, client가 http request를 보냈더니, http response로 경고 메시지가 온 것입니다. 그렇다면, 이 상황에서 TCP 연결은 어떻게 된 것이고, 누가 이 메시지를 보낸 것일까요?
- 처음부터 따라가 보겠습니다. 첫 번째로 DNS protocol로 사이트의 IP를 알아 옵니다. 이후 client는 TCP SYN를 보냅니다. TCP SYN는 gateway router를 통해서 server로 이동할 겁니다. 이때, 특정 기관에서 이 GWR에서 server로 가는 IP를 막는다면, client의 브라우저는 흰색으로 아무것도 뜨지 않을 것 입니다. 하지만, 우리가 받은 것은 경고 메시지임으로 바로 막지 않은 것 같습니다. server는 SYN을 받고 SYN ACK를 보냅니다. Client는 SYN ACK를 받고 http request를 보냅니다. 여기까지 해서 TCP 연결이 되었습니다.
Http request는 GWR를 통과할 때, router는 이 PKT를 가로채고, 새로운 http response를 만듭니다. 만들 때, 가로챈 PKT안에 있던 source IP와 dest IP를 넣어서 마치 server가 보낸 것 처럼 만듭니다. 그리고 data로는 우리가 보게 될 경고 메시지를 넣습니다. 그 결과 우리는 위와 같은 메시지를 보게 됩니다. - GWR가 client와 server 간의 TCP 연결 자체를 허용한 이유는, GWR이 client와 TCP 연결을 하면 GWR에 과부화가 오기 때문이다. 그래서 TCP 연결은 허락하고 이후에 보내는 메시지를 감시하다가 낚아채서 경고 메시지를 보냅니다.
- HTTPS는 위 경고 메시지가 불가능합니다. HTTP의 내부 IP들이 암호화 되어 있기 때문에 GWR는 PKT들의 최종 목적지가 어딘지 알 수 없습니다. 그래서 https로는 많은 사이트들에 접근이 가능합니다.
