재현이의 일상

[SSL의 개념]

일반적인 웹사이트에서 HTTP를 사용한다면 아래 그림과 같이 보안이 전혀 고려되지 않은 채로 패킷이 교환된다. 중간에 해커가 가로챘을 경우에 어떻게 해볼 도리가 없다. 예를 들어 amazon.com에서 신용 카드를 사용해서 책을 구매했다고 할 때 일반 사용자가 입력한 카드번호는 수많은 경로를 거치게 된다. 아마 수십 개의 라우터를 거쳐야만 amazon.com의 웹 서버와 정보를 교환할 수 있을 것이다. 이렇게 개방된 환경에서 중요한 데이터를 그냥 보낸다는 것은 위험한 일이며 적절한 보안이 반드시 필요하다고 할 수 있다.

앞의 네트워크의 개념에서 다룬 내용이지만 다시 한번 설명하면 네트워크에 연결된 각각의 컴퓨터가 서로 패킷을 교환하기 위해서는 여러 개의 레이어를 둔다고 하였다. TCP는 데이터가 적절하게 전송이 되었는지 확인하는 역할을 하고, IP는 각각의 데이터가 정확한 위치로 배달되도록 도와주는 역할을 한다. HTTP는 단지 웹 브라우저와 웹 서버간의 데이터 교환을 위한 규약이다. 패킷에 대한 보안을 강화하기 위해서 오른쪽 그림에서는 SSL이라는 통로를 지나가도록 한다. 웹 브라우저나 서버의 입장에서는 기존의 HTTP 프로토콜에 전혀 변화를 주지 않은 채로 SSL이라는 통로를 패킷이 지나가도록 하면 보안에 대한 처리가 이루어진다. 이것이 SSL의 개념이다. 영어에서도 알 수 있듯이 하나의 보안을 위한 ‘레이어’ 역할을 하는 것이 SSL이다. SSL은 HTTP 프로토콜 이외에 많은 어플리케이션 레이어의 프로토콜을 지원한다.

패킷을 암호화하기 위해서 사용하는 방법은 SSL 이외에 Secure HTTP와 같이 HTTP 자체에 보안 기능을 넣는 방법과 IPSEC과 같이 IP에 보안을 추가하는 방법도 있으나 가장 널리 사용하는 방법은 역시 SSL이다.

해킹을 통해서 실력을 인정받고 싶어하는 해커가 많은데 반해, 현재 SSL에 대한 해킹이 이루어졌다는 이야기가 들리지 않는 것으로 보아 SSL은 해킹에 대해서 매우 정교한 구조를 가지고 있다고 할 수 있다.

단순히 패킷을 암호화 시켜서 보내고, 받는 쪽에서는 패킷을 다시 해석해서 사용하는 구조라면 SSL은 이미 해커에 의해서 해킹이 되었을 것이다. 그러나 SSL은 이외에 별도의 과정을 거쳐서 데이터를 안전하게 보낼 수 있는 기능을 제공하고 있다.

[보안 통신의 구성 요소]

암호화 방법에 대해서는 수천 년간의 관심거리였다. 아무래도 인간이 비밀리에 작업하는 일이 많기 때문이 아닌가 한다. 한 쪽에서는 “어떻게 암호화를 할 것인가”가 관심거리인 반면 다른 한쪽에서는 “어떻게 암호를 풀것인가”였다. 일반적으로 안전한 통신을 위해서는 다음과 같이 세 가지가 만족되어야 한다.

(1)보내고자 하는 내용을 특정 사람만 읽을 수 있어야 한다.

(2)받는 사람은 보낸 사람에 대해서는 신뢰를 할 수 있어야 한다.

(3) 주고받는 정보가 변형되지 않아야 한다.

위 세 가지의 조건을 만족해야 정말 안전하게 메시지가 교환되었다고 할 수 있다. 그럼 각각의 조건을 만족시키기 위해서 어떤 방법이 사용되는지 알아보도록 하자.

첫 번째, 보내고자 하는 내용을 특정 사람만 읽을 수 있어야 한다는 것은 내용을 누구나 닑을 수 없고 수신인만 읽을 수 있도록 암호화되어야 한다는 것이다. 고구려의 유명한 설화인 바보 온달 이야기에서 평강공주가 아버지인 평원왕의 눈을 피해 사랑의 메시지를 보낸다고 가정해 보자. 평강공주는 바보온달과 메시지를 교환하기 위해서 비밀 코드를 만들었다.

두 사람은 서로 만나는 약속을 하는데 필요한 정보를 위와 같이 암호화해서 보내고 자신들이 보낸 메시지는 코드표가 있어야 읽을 수 있기 때문에 평강공주는 자신이 보낸 메시지는 바보온달만 읽을 수 있다는 것을 믿을 수 있게 된다. 물론 실제 세계에서 암호화를 이렇게 단순하게 하지 않는다.

그럼 바보온달은 메시지가 평강공주로부터 온 것을 어떻게 확신할 수 있을까? 평강공주와 바보온달 사이에 메시지를 교환할 때 서로 특정 사인을 뒷면에 적기로 했다면 바보온달은 평강공주로부터 온 메시지가 평강공주로부터 온 것을 확신할 수 있게 된다. 이런 식으로 두 번째 조건인 ‘받는 사람은 보낸 사람에 대해서 신뢰를 할 수 있어야 한다.’를 만족할 수 있다.

그런데 메시지에서 MCM9라는 메시지를 중간에 누군가가 빼서 보낸다면, 가장 중요한 정보가 빠지고 그냥 ‘사랑한다’라는 단순한 편지가 되어버리고 만다. 바보온달이 메시지를 받을 때 정말 평강고주가 보낸 메시지에 누가 빼거나 더하지 않았는지 어떻게 믿을 수 있을까? 메시지가 변경되지 않았다는 것을 확인하기 위해서 hash 함수를 사용한다. 전체 메시지에 대해서 hash 함수를 돌리게 되면 유일한 값을 얻을 수 있다. 평강공주는 이 값을 메시지에 비밀값으로 적어놓는다. 메시지를 받은 바보온달은 다시 받은 메시지를 hash 함수에 넣고 돌린 결과가 평강공주가 적어 놓은 값과 일치하면 메시지가 변경되지 않았다고 믿을 수 있게 된다. 만약 평원왕이 메시지를 가로채 수정해서 바보온달에게 보낸다면 바보온달은 수정된 메시지를 hash 함수에 넣게 되고, 그 결과가 평강공주가 보낸 것과 일치하지 않기 때문에 메시지가 수정되었다는 것을 알게 된다. 보통 흔히 사용하는 hash 알고리즘으로는 MD5(Message Digest5)와 SHA(Secure Hash Algorithm)이 있다. 시스템 엔지니어의 입장에서는 이 알고리즘을 알 필요는 없을 것 같다.

[암호화의 종류]

암호화의 방법은 크게 두 가지로 나눌 수 있다. ‘비밀키 암호화’ 방법과 ‘공개키 암호화’ 방법으로 나눌 수 있다.

비밀키를 사용해서 암호화를 하는 경우는 앞에서 평강공주와 바보온달의 사랑의 메시지 예제에서 볼 수 있듯이 두 사람 모두 암호를 해독할 수 있는 키를 가지고 있어야 하기 때문에 ‘대칭적 암호화’라고 부른다. 이에 비해 ‘공개키 암호화’ 방법은 두 사람이 다른 키를 가지고 메시지를 주고받기 때문에 ‘비대칭적 암호화’라고 부른다.

=======================================================================

[TIP]

[키란 무엇인가?]

암호화에 대한 이야기가 나오면 반드시 나오는 용어가 바로 ‘key’라는 용어이다. 한국어로는 ‘열쇠’로 번역할 수 있다. 물론 번역을 하지 못하는 독자는 없을 것이다. 그런데 ‘열쇠’라는 단어 속에 키에 대한 모든 의미가 들어가 있다. 우리가 열쇠를 사용하는 이유는 열쇠를 가지고 있는 사람들만이 금고를 연다든지 집의 문을 연다든지, 또는 반대로 금고를 닫고 집의 문을 닫기 위해서이다. 이와 마찬가지로 암호화해서 나오는 키는 해당 메시지를 암호화, 해독하기 위해서 특정 사람들만 가지고 있는 열쇠가 바로 ‘key’이다.

===============================================================================================

[“비밀키 암호화” 기법]

대칭적 암호화는 메시지를 주고받는 두 사람간에 똑 같은 키(대칭적 키)로 암호화를 하고 다시 이 키를 통해서 해독을 하기 때문에 ‘대칭적 암호화’ 방법이라고 이전에 설명하였다. 위의 그림을 보면 데이터를 암호화하는 데 쓰이는 키와 암호를 해석하는데 쓰이는 키가 똑같다. 대칭적 암호화는 역사적으로 일반화된 암호화된 기법이라고 할 수 있다. 메시지를 교환하는 사람들만이 비밀키를 공유하고 있다면 메시지는 안전하게 교환된다고 믿는 방법이다. 그러나 컴퓨터의 세계에서는 키라는 것이 비트의 나열로 나타낼 수 밖에 없다. 키의 크기가 작다면 아무래도 다른 사람이 키를 알아낼 수 있는 확률은 높아진다. 우리가 집에 열쇠를 달 때 보조키를 사용하느냐 생체 인증 시스템을 사용하느냐와 같은 암화 수준을 말하는 것이다. 현재 전자 상거래에서 사용하는 SSL은 56비트와 128비트가 있으나 아무래도 128비트 암호화키를 사용하는 것이 훨씬 높은 수준의 보안을 제공하는 것이다.

[“공개키 암호화”기법]

앞서서 이야기한 비밀키 암호화 기법은 한 가지 중대한 문제를 가지고 있다. 적어도 한번은 평강고주와 바보온달이 만나서 요런 요런 키를 우리끼리만 사용을 하자는 합의를 해야 한다. 그러나 인터넷 환경에서는 두 사람이 만나서 서로의 키를 주고받고 이런 키를 사용해서 서로 메시지를 주고받자고 합의를 할 수가 없다. 또, 온라인 상으로 이 키를 주고받다가 이 키가 해킹을 당했을 경우 나머지 메시지의 안전을 보장할 수가 없다.

이런 문제점 때문에 요즈음 나온 것이 바로 ‘공개키 암호화’ 기법이다. 공개 암호화 기법은 기존의 비밀키 암호화 기법과 같이 메시지를 교환하고자 하는 두 사람이 모두 같은 키를 가지고 있지 않는다. 따라서 ‘비대칭적 암호화’라고 부른다. 두 사람이 가지고 있는 각각의 키를 ‘공개키’와 ‘개인키’로 부른다. 공개키는 여러 사람이 모두 공유할 수 있는 키이고 개인키는 오직 한 사람만이 가지고 있는 키이다. 이런 공개키에 기반한 암호화 구조를 PKI라고 부른다. 앞에서 설명한 평강공주와 바보온달의 이야기를 조금 더 진행해 보겠다. 평강공주가 몰래 넣어둔 비밀 코드를 그만 아버지에게 들켜 더 이상 이전의 방법으로는 안심하고 연애 편지를 쓸수가 없어서 바보온달은 새로운 방법으로 편지를 교환하기로 했다. 바보온달이지만 꽤 똑똑하다.

바보온달은 개인키와 공개키를 만든다. 공개키로 암호화된 데이터는 개인키를 이용해서만 해석할 수 있어야 한다. 물론 개인키로 암호화된 데이터는 공개키를 사용해서 해석할 수 있다. 그리고 바보온달은 성문 앞 게시판에 자신이 만든 공개키를 대문짝만하게 붙인다. 평강공주는 그 공개키를 받아 자신이 보내고자 하는 메시지를 공개키를 이용해서 암호화한다. 평강공주는 자신의 메시지를 해독할 수 있는 사람은 오직 바보온달이기 때문에 안심하고 데이터를 보낼 수 있게 된다.

===============================================================================

[NOTE]

[디지털 서명]

앞의 바보온달과 평강공주의 이야기에서 서로의 메시지가 변경되지 않았다는 것을 확인하기 위해서 비밀값을 적어 놓는다고 했다. 이 비밀값을 보통 디지털 서명이라고 한다. 디지털 서명은 데이터가 수정, 변경되는 것을 막아준다.

해쉬 알고리즘을 사용하면 문서에 대해서 유일한 값(One-way hash)을 얻을 수 있다. 이 값을 개인키로 암호화해서 원래의 데이터와 함께 보낸다. 받은 쪽에서는 받은 데이터를 다시 똑 같은 해쉬 알고리즘을 사용해서 다시 유일한 값을 도출해 낸다. 그리고 보낸 사람으로부터 온 디지털 서명을 자신의 공개키를 사용해서 해석을 한 다음에 이전에 값과 비교를 해서 두 개가 일치를 한다면 문서는 변경이 되지 않았다는 것을 믿을 수 있게 된다.

===================================================================================================

바보온달과 평강공주는 이런 방법으로 몇 일간을 서로 편지를 통해서 이야기할 수가 있었다. 그러나 서로의 이야기가 길어지게 되자 암호화고 해석하는데 너무 많은 시간을 할애해야만 했다. 어떤 날은 A4 한 장을 해석하기 위해서 하루 종일 매달린 적도 있게 되었다.

공개키, 암호화 방법은 메시지를 주고받는데 확실한 보안을 제공하지만 암호화하고 해석하는데 시스템은 많은 비용을 치뤄야 한다. 따라서 인터넷을 사용할 때 모든 데이터를 암호화해서 보낸다는 것은 시스템에게는 엄청난 부하를 주게 된다.

다시 바보온달과 평강공주의 이야기로 돌아가 보자. 암호화하는데 너무 많은 시간이 걸리자 평강고주는 더 좋은 방법을 생각해 냈다. 기존에 사용했던 방법과 새로운 방법을 조합하기로 한 것이다.

위의 그림에서 볼 수 있듯이 서로가 메시지를 주고받기 위한 단계는 많아졌지만 비밀키를 한번만 교환하게 되면 다음 메시지를 주고받을 때에는 훨씬 간단해진다는 점이 평강공주가 바보온달보다는 한수 위라는 것을 보여준다.

비밀키라는 것이 등장하고 이 비밀키를 서로 주고받기 위한 과정은 공개키를 사용한 방법과 동일하다. 그러나 메시지를 공개키를 사용해서 주고받는 것이 아니라 의사 소통을 위해서 필요한 코드와 같은 비밀키만을 주고받는다. 그리고 나서 이 비밀키를 가지고 의사 소통을 하면 되니 이전 보다 훨씬 암호화하고 해석하는 작업이 편해졌다고 할 수 있다.

[인증서와 CA(Certificate Authority)]

이제 바보온달과 평강공주는 안심하고 메시지를 주고받을 수 있게 되었을까? 답은 아니다. 지금까지의 과정을 예리하게 지켜본 독자라면 알 수 있겠지만 만약 성문 앞에 공개키를 붙여놓은 사람이 바보온달이 아니라 옆나라 왕자라면 큰일이 아닐 수 없다. 아무나 공개키, 비밀키를 만들 수 있는 상황이라면 공주의 입장에서는 성문 앞의 공개키가 바보온달의 것인지 아니면 옆나라 왕자가 바보온달인 척하며 붙여놓은 것인지 알 수가 없다.

온라인 상에서 카드를 입력했는데 사용자는 입력한 사이트가 신뢰할 수 있는 amazon.com이라고 믿었는데, 유령 회사였다면 사용자는 막대한 금전 손실을 입을 수밖에 없다. 이러한 문제를 해결하기 위해서 등장한 것이 CA(Certificate Authority)이다. 굳이 비유를 하자면 주민등록증을 발급해주는 동사무소와 같은 역할이다. 우리가 주민등록증을 믿는 이유는 곡가라는 신뢰할 수 있는 기관에서 발행한 신분증이기 때문이다. 여기서 국가에 해당하는 인터넷 기관이 CA이다. CA는 verisign이나 thawte와 같은 기관이 있다. 이처럼 공개키에 대해서 인증 기관이 인증서를 발부하고 그 기관이 인증서를 보장해준다면 인터넷과 같이 개방된 공간에서도 서로를 믿고 거래할 수 있게 된다. 반대로 인증서를 받은 사람이나 업체는 인증서를 다른 사람이 악용하지 못하게 보관할 책임이 있다. 이런 이유 때문에 인증서를 인증기관으로 받기 위해서는 대단히 까다로운 절차를 거쳐야 겨우 받을 수 있다.

인증 기관으로부터 인증서를 받게 되면 아래와 같이 인코딩된 데이터를 웹 브라우저에서 보여준다. 웹 브라우저에서 보이는 문자를 편집기에 그대로 복사해서 도메인이름.crt라는 이름으로 파일을 저장하면 인증 기관으로부터 인증서를 받은 것이다. 복사를 할 때에는 불필요한 문자가 들어가지 않도록 조심해야 한다.

위의 인코딩된 데이터를 사람이 읽을 수 있는 형식으로 바꾸면 아래와 같다. Issuer는 인증서를 발행한 기관의 이름이고 Validity는 인증서의 유효 기간이다. 읹,d서는 한번 받으면 영원히 유효한 것이 아니다. 보통 매년 인증서를 갱신해야 하는데, 갱신되지 않은 인증서는 사용할 수가 없다. Subject는 인증서를 받은 기관 또는 사람의 이름이며 Signature는 인증 기관의 서명이다.

이 파일을 윈도우 운영체제에서 탐색기를 통해 더블 클릭을 하면 보다 편하게 볼 수 있다. 첫번째 일반 탭을 보면 간략하게 인증서의 내용을 볼 수 있다. 발행 기관이 어디이고 누구에게 발행됐는지 유효 기간은 언제부터 언제까지인지를 알 수 있다.

두 번째 탭을 누르면 보다 자세한 인증서의 정보를 볼 수 있다. 위에서 설명한 인증서의 내용을 보다 편하게 요약해 놓은 것이다.

세 번째 탭을 눌러보면 인증의 계층 구조를 확인할 수 있다. 인증의 계층 구조에 대해서는 다시 설명하도록 하겠다. 현재는 바로 Thawte라는 인증 기관으로부터 인증을 받은 것으로 이해하고 넘어가도록 하자.

이제 앞에서 이야기하지 않은 인증 기관에 대해서 알아보도록 하자. 인증서를 발행하는 서버를 인증 서버라고 한다. 인증 서버는 모든 사람이 운영할 수 있다. 우리가 인증 서버를 운영하고 인증서를 발행한다고 하더라도 다른 사람이 내가 발행한 인증서를 믿지 못한다면 그 인증서는 무용지물이 되고 만다. 그러나 어떤 회사에서 인증 서버를 운영하고 있고, 이 회사 내의 모든 컴퓨터는 이 인증 서버로부터 발행된 인증서를 믿기로 했다. 이와 같이 사설 인증 서버를 운영하더라도 인증서를 사용하는 컴퓨터끼리 약속되어 있다면 개인 또는 특정 회사가 발행한 인증서는 유효하다. 하지만 우리에게 인증서가 필요한 곳은 익명성이 보장되는 인터넷이다. 이런 환경에서는 모든 컴퓨터가 신뢰할 수 있는 기관으로부터 발행된 인증서만이 유효하다. 따라서 인증서의 유효성은 얼마나 많은 컴퓨터가 그 기관을 신뢰하느냐가 중요한 이슈가 된다.

우리는 이런 인증기관을 보통 Root CA라고 부른다. 웹 브라우저를 처음 설치했다면 자신의 웹 브라우저에 기본적으로 설정되어 있는 Root CA를 확인할 수 있다. 인터넷 익스플로러의 [도구] 메뉴에서 [옵션]을 클릭한 후 [내용] 탭을 누른다. [내용] 탭 안에 있는 [인증서] 버튼을 클릭하면 다시 ‘인증서’ 다이얼로그 상자가 하나 더 뜨는데, 이 다이얼로그에는 현재 컴퓨터에 설치된 많은 인증서를 확인할 수 있다. 다시 [신뢰된 루트 인증기관] 탭을 누르면 많은 Root CA 인증서가 출력된다.

항목 중에 하나를 클릭하면 이 인증서는 다른 인증서와 약간 다르다. 다른 인증서의 경우는 발행 기관이 대부분 Root CA이고 발행 대상이 자신의 회사가 되는 반면에 인 인증서는 발행 기관과 발행 대상이 일치한다. Root CA의 경우는 자신이 발행을 하고 자신이 발행을 받기 때문에 일치한다. Root CA를 제외하고는 두 개의 항목이 일치할 수는 없다.

이제 인증이 계층적으로 이루어지는 관계에 대해서 이야기해 보자. 계측적 인증 구조를 보면 네트워크에 흐르는 정보를 지키는 것이 얼마나 효율적으로 이루어지고 있는지 알 수 있다. 인증서를 발행하는 것에 효율성을 높이기 위해서 인증서는 계층적으로 이루어져 있다. 아래 그림과 같이 Root CA는 자기 자신에 대해서 자기가 서명을 하는 인증 기관이다.

하위 인증 기관인 USA CA는 Root CA로부터 인증을 받고 Engineering CA는 USA CA로부터 인증을 받았다. 사실 Root CA를 제외한 다른 인증 기관은 클라이언트가 신뢰할 수 있는 인증 기관은 아니다. 그러나 인증 체인을 따라가면서 Engineering CA가 발급한 인증서도 신뢰할 수 있는 인증서로 클라이언트는 간주한다.

아래는 인증서를 확인하는 프로그램이 Engineering CA로부터 발급 받은 인증서 역시 유효하다는 것을 확인하는 절차에 대한 그림이다. 인증 체인(Certificate Chain Verification)은 주어진 인증서가 유효한 인증서인지 확인하는 절차를 말한다. 인증서를 검사하는 프로그램은 Engineering CA로부터 받은 인증서의 유효 기간이 남았는지 확인하고 Engineering CA가 신뢰할 수 있는 CA인지 확인한다.

Engineering CA가 신뢰할 수 없는 CA이기 때문에 Engi-neering CA에게 인증서를 발급해준 USA CA에 똑 같은 절차로 유효성 검사를 하게 된다. 하지만 USA CA는 신뢰할 수 있는 Root CA로부터 인증서를 받았기 때문에 인증 체인이 멈추고 Engineerring CA로부터 받은 인증서는 유효하다고 판단을 하게 된다.

한번 이런 절차를 거쳐서 인증된 Engineering CA는 신뢰할 수 있는 CA로 시스템에 등록되게 된다. 이러한 인증 기관을 중개 인증 기관(Intermediate CA)이라고 부른다. 자신의 웹 브라우저에 등록된 중간 인증 기관의 리스트를 보고 싶은 경우 이전에 보았던 ‘인증서’ 다이얼로그에서 [중개 인증 기관] 탭을 누르면 확인할 수 있다.

[SSL Handshake]

앞에서 바보온달 설화를 통해서 SSL 보안 통신 개념을 쉽게 설명을 하였다. 실제 클라이언트와 서버간의 통신은 바보온달과 평강공주의 메시지 전달과 유사하다. 이제부터는 지금까지 지식을 가지고 서버와 클라이언트간에 안전한 통신을 하기 위해서 어떤 과정을 거치는지 알아 보도록 하자.

핸드쉐이크에 대해서는 TCP 프로토콜을 설명할 때 언급하였다. SSL에서 핸드쉐이크를 하는 것은 TCP 프로토콜에서 핸드쉐이크를 하는 것과 비슷하지만 TCP가 단순히 데이터를 정상적으로 보내는데 초점이 맞추어져 있는 반면, SSL에서의 핸드쉐이크는 정보를 안전하게 보내는데 초점이 맞추어져 조금 더 복잡한 과정을 거친다.

클라이언트는 서버에게 ‘Client Hello’ 메시지를 보내서 인사를 한다. 클라이언트가 보낸 메시지에 서버는 ‘Server Hello’로 답을 한다. 클라이언트가 메시지를 보냈지만 서버가 응답이 없다면 에러가 발생한다. 클라이언트는 ‘Client Hello’ 메시지를 보낼 때 자신이 지원할 수 있는 SSL 버전 중에서 가장 높은 버전, 암호화를 할 때 사용하는 임의의 32바이트의 값, Session ID, 자신이 지원하는 암호화 패키지 등을 같이 보낸다. 물론 처음 메시지를 보낼 때에는 Session ID가 비어있지만 다음에 메시지를 보낼 때는이전의 Session ID를 실어서 보낸다. 따라서 두번째 통신을 할 때에는 보다 빠르게 통신할 수 있다.

클라이언트의 인사에 서버는 ‘Server Hello’ 메시지로 답을 한다고 했다. ‘Server Hello’ 메시지에는 클라이언트가 제시한 SSL 버전의 수용 유무를 판단한다. 만약 클라이언트가 SSL 버전 3.0으로 통신을 하자고 제안했지만 서버는 버전 2.0밖에 지원하지 못한다면 통신은 SSL 버전 2.0으로 통신을 하게 된다. 그러나 요즈음에 나오는 거의 모든 클라이언트와 서버는 SSL 버전 3.0을 지원하지 못하기 때문에 일반적인 상황이라면 SSL 버전 3.0으로 통신한다고 생각하면 된다. 또한 ‘Server Hello’ 메시지 안에는 클라이언트가 보낸 암호화 리스트 중에서 서버가 선택한 암호화 알고리즘도 클라이언트 쪽으로 함께 보낸다. 이외에도 ‘Sefver Hello’ 메시지에는 클라이언트가 보낸 임의의 랜덤값, 서버가 지정한 Session ID가 같이 들어 있다.

클라이언트와 사버는 앞의 과정을 통해서 통신을 하기 위한 가장 기초적인 상황 파악 단계를 마친다. 이제는 서로 메시지를 암화하기 위해 사용할 키를 주고받는 과정이 남아 있다.

앞에서 이야기했듯이 클라이언트와 서버간의 통신을 위해서는 ‘비밀키’와 ‘공개키’ 방식을 모두 사용한다.

두 가지 방식을 모두 사용하기 때문에 약간 복잡할 수도 있으나, 바보온달 이야기를 완전히 이해했다면 그리 어려울 것은 없다. 일단 서버는 ‘ServerHello’ 메시지를 전달하고 난 후에 ‘Certificate’ 메시지를 보내서 앞으로 서버가 보낼 공개키는 이런 이런 기관에서 공식적으로 인정해줬으니, 믿고 자신과 통신해도 좋다는 것을 알린다. 그리고 난 연후에 ‘SeverKeyExchange’ 메시지 속에 ‘공개키’를 실어서 보낸다. 그리고 나서 서버는 ‘ServerHelloDone’ 메시지를 보내서 서버의 기본 작업이 모두 끝났다고 클라이언트에게 알린다.

클라이언트는 서버로부터 ‘ServerHelloDone’ 메시지를 받으면 앞으로 통신할 때 사용할 비밀키 또는 세션키를 서버가 준 공개키를 사용해서 생성하고 이 키를 ‘ClientKeyExchange’ 메시지에 실어서 서버에게 보낸다.

키를 서로 교환한 클라이언트와 서버는 이제 보안 서비스를 사용하기 위한 세세한 스팩을 서로 교환해서 암호화 방법을 동기화시킨다. 이 과정이 ‘ChangeCipherSpec’,’Finish’의 단계이다. 이로써 모든 핸드쉐이크 과정이 끝나게 된다. 이제 어플리케이션 레이어에서 데이터를 서로 주고받아도 안전한 데이터 교환이 보장된다.