보통 인하대를 나오고 권장우 교수님의 네트워크 과목을 들었다면 TCP의 3-way handshake, 4-way handshake에 대해 많이 들었을 것이다. 하지만 SSL Handshake에 대해 들어본 적은 없을 것이다.(보안쪽에서 나오려나..) 배운적이 없지만 유튜브, 생활코딩(https://opentutorials.org/course/228/4894), 구글링(https://www.ibm.com/support/knowledgecenter/en/SSFKSJ_7.1.0/com.ibm.mq.doc/sy10660_.htm)을 합쳐서 한번 어떤 개념인지 정릴르 해보려고 한다. 꼭 필요한 개념이라 생각하고(여러가지를 구성하는데 있어서) 면접에서도 많이 물어보기 때문이다.

TLS/SSL은?

SSL(Secure Sockets Layer)은 Certificate Authority(CA)라 불리는 서드 파티로부터 서버와 클라이언트의 인증을 하는데 사용된다. 주로 전송계층과 응용계층 사이에서 보안조치를 하는데 사용하게 된다. 우리들이 많이 접하게 되는 HTTPS://는 SSL을 사용하는 경우를 의미한다. TLS(Transport Layer Security)로 최근에 부르는데 SSL은 과거 명칭이라고 한다.(고로 같은 말)

시작하기 전 공개키와 대칭키에 대해 간단히 정리해보고 시작하려고 한다.

공개키와 대칭키 방식

  1. 대칭키

    그림을 보자. 그림을 보게 되면 두 사람은 하나의 내용을 주고 받을 때 암호화 후 내용을 전달하고 복호화를 하여 읽게 된다.그리고 이 때 같은 키(대칭키)를 사용하는 방식이다. 이 경우 대칭키가 있게 되면 내용을 모두 읽을 수 있게 된다. 속도가 빠른 장점이 있지만 만약 누군가가 이 대칭키를 악의적으로 가진다면 내용을 별다른 노력없이 볼 수 있게 된다.

  2. 공개키
    그림을 보게 되면 오른쪽에 글을 읽고 있는 사람을 서버(데이터를 받는 수신 측)이라고 보겠습니다. 그리고 이 수신측에는 수신측만 가지는 private key를 가질 수 있습니다. 데이터를 암호화 할 때 어떤 키를 사용하느냐에 따라 암호의 의미를 가질지 서명의 의미를 가질 지 고민해 볼 수 있습니다.

    • 공개키 암호: 암호로 사용될 경우 공개 공개키를 가지고 내용을 암호화 하게 됩니다. 그리고 이 내용은 private key를 가진 경우에만 열람이 가능해 집니다.
    • 공개키 서명: 서명 용도로 사용 될 경우 private key를 가지고 암호를 하게 됩니다. 그리고 이 내용은 공개키를 통해 열 수 있게 되는데 이 경우 공개키를 가지는 누구나 이 내용을 열 수 있게 되지만 이 내용을 어느 쪽에서 서명 된 것인지 알 수 있게 됩니다. 브라우저에서는 이 방식을 사용하게 됩니다.

SSL 인증서란?

클라이언트와 서버간의 통신을 제 3자가 보증화 해주는 전자화된 문서이다. 통신내용이 공격자에게 노출되고 악의적으로 변경되는 것을 막고 서버의 신뢰성을 올릴 수 있다. 인증서의 목표는 클라이언트가 접속한 서버가 신뢰 할 수 있는 서버인지를 판단하고 SSL 통신에 사용될 공개키를 클라이언트에게 전달하는 것이다. 위에서 언급한대로 SSL인증서에는 두가지 내용이 들어가는데 첫번째는 서비스의 정보(CA, 도메인) 두번째는 서버측 공개키이다.

그럼 CA(Certificate Authority)는 뭔가?

SSL인증서를 기준으로 클라이언트가 접속한 서버가 클라이언트가 의도한 서버가 맞는지를 확인을 하게 된다. 이러한 일을 해주는 공인된 회사들을 CA라고 한다. 이러한 CA는 브라우저가 리스트를 가지고 있고 이 CA들의 공개키들을 가지고 있다

인증서로 서버가 신뢰할 수 있는지 어떻게 판단할까?

위에서 말했던 공개키 서명방식을 사용한다. 브라우저는 위에서 말했듯 신뢰할 수 있는 사이트와 그 사이트의 공개키를 가지고 있다. 웹 브라우저가 서버에 접속한다면

  1. 서버는 SSL 인증서를 제공한다. 이 인증서에는 서버측의 공개키와 서비스의 정보를 담고있다.
  2. 브라우저는 이 인증서를 발급한 CA가 자신의 CA리스트에 있는지 확인한다.
  3. 있다면 CA의 해당 공개키를 이용해서 인증서를 복호화한다. 복호화가 된다면 이 인증서는 CA의 비공개키에 의해 암호화 되었다는 것을 알 수 있다.

SSL Handshake란?


  1. client Hello: client에서 SSL버전 정보와 지원하는 암호화 방식, 무작위 바이트 문자열(이후에 사용하게 되는 중요한 데이터입니다)이 포함 되어 전달 됩니다. 이미 SSL handshake를 했었다면 세션을 재사용 할 수 있습니다.
  2. server Hello: 지원하는 암호화 방식 중 서버에서 어떤것을 사용할 지, 세션 ID, 서버측에서 생성한 무작위 바이트 문자열을 전송합니다. 클라이언트에서 인증서를 요구하게 되면 SSL 인증서를 전송하게 됩니다.
  3. 인증서를 받게 되면 위에서 언급했던 방식(인증서가 서버가 신뢰할 수 있는지 어떻게 판단할까?)로 신뢰할 수 있는 사이트 인지 판단하게 됩니다.이 과정을 통해 클라이언트는 공개키를 얻게 됩니다.
  4. 이후 클라이언트는 자신이 만든 무작위 바이트 문자열과 서버쪽에서 전송된 무작위 바이트 문자열을 조합하여 pre master secret키를 생성합니다. 이 키는 이후 데이터를 주고 받을 때 대칭키 방식을 사용할 때 사용하게 됩니다. 이 pre master secret키를 서버로 전송할 때 인증서에서 받았던 키를 이용하여 공개키 방식 암호화를 하게 됩니다. 그리고 서버쪽으로 전송하게 됩니다.
  5. 서버쪽에서는 수신한 pre master secret키를 비밀키를 이용하여 복호화 하여 얻게된다.
  6. server client 둘 다 일련의 과정을 거쳐 pre master secret키를 master key로 만들게 되고 이 master key를 이용하여 session key를 만들게 된다. 이후 데이터를 주고 받을 떄 session key를 대칭키 방식으로 이용하여 통신하게 됩니다.
  7. 통신이 끝나면 세션키를 폐기합니다.

마치면서

최대한 단순하게 정리하려고 노력했다. 아직 잘 안와닿지만 평소 궁금했던 HTTPS의 연결과정과 이후에 사이트를 설계할 때 어떤 방식으로 설계하는 것이 보안적인지 고민해 볼 수 있었다.