SSL / HTTPS

0

네트워크

목록 보기
7/8

Secuer Socket Layer (= TLS, Transport Layer Security Protocol)

우리가 흔히 사용하는 HTTPS에 적용되는 프로토콜이다.


즉 이 사진처럼, SSL 위에 여러 프로토콜이 동작함을 의미하는 사진이다.

HTTPS = (HyperText Transfer Protocol over Secure Socket Layer)
Port = 443

예전 산업보안관리사 취득, 정보통신기술, 전자정보보안기술 강의를 들었을 때를 잘 상기하면 좋겠다. Client(=Browser)가 인증서의 유효를 CA를 거쳐 확인을 하고 Server와 통신을 하는 그 과정을 떠올리면서 게시글을 작성하자.

SSL은 CA (Certificate Authority), Server, Client 간의 인증을 위해 사용된다.

우리는 Internet을 무의식적으로 사용하고 있지만 , 그 뒤에는 보안을 위한 여러가지 기술들이 적용되는데 SSL은 그 중 하나다. 가끔 구글링을 하다보면, HTTPS 적용이 안되었다고 경고창이 뜨는 것을 본 적이 있을 것이다.

HTTPS가 아니라 HTTP가 적용되어 있기에 그렇다.

이게 왜 문제냐면,
1. 우리는 별다른 절차 없이는 Server가 "진짜" 인지 아닌지 구분이 불가능하다. 그니까, Phihsing이나 Pharming의 위험을 가진다는 뜻이다.
2. 암호화되지 않은 방법으로 Data가 전송된다. 그래서 누가 감청하면 다 보인다.

이러한 문제를 해결하기 위해서 SSL이 적용된 HTTP를 사용하고, 그 결과 우리는 (1) 신뢰할 수 있는 Site에 정보를 전송하면서, (2) 누가 Packet을 감청하더라도 어떤 내용인지 알 수 없도록 암호화 Key를 주고 받고 암호화를 통해 정보를 주고받아야한다.

그럼, HTTPS의 동작과정을 먼저 살펴보자.

  1. Server는 Client들에게 신뢰성을 보장하기 위해 CA에게 SSL 인증서를 발급받는다.
  2. CA는 SSL 인증서에 Server의 Domain, 인증서를 발급한 CA 등의 정보, Server의 공개 키를 담아 발급해준다. 이 때, 인증서는 "CA"의 비공개 Key(공개 Key 암호화 방식)로 암호화한다.
  • 공개키는 추 후 Client가 사용하여 Server를 검증할 때 사용한다.
  1. Client(=Browser)는 Server에 접속하면서 Server가 CA로부터 발급받은 SSL 인증서를 "CA"의 공개 Key로 SSL 인증서를 복호화한다. 복호화가 된다면 CA가 미리 신뢰할 수 있는 Site임을 확인하고 SSL 인증서를 발급했다는 뜻이므로 이 순간부터 Client는 Server를 신뢰할 수 있다.
  2. 우리는 SSL 인증서를 CA을 공개 Key로 복호화했고, SSL 인증서에 담긴 Server의 공개 Key를 얻었다. 그럼 이제 Client와 Server의 통신에 사용할 "대칭 Key"Server의 공개 Key로 암호화 하여 전송한다.
  3. 그럼 Server는 Server의 공개 Key 로 암호화된 Client의 대칭 KeyServer의 비공캐 Key로 복호화 하여 안전하게 대칭 Key를 주고 받는 과정을 마무리한다.

이게 전체적인 HTTPS의 동작과정인데, 그럼 SSL은 도대체 "정확"하게 어디에 사용되는거냐? 라고 물어본다는 질문에 대답하기 위해서 실제 packet을 통해서 살펴보자

Client Hello ~ ChangeCipherSpec은 HTTPS를 위해 Key를 주고받는 과정이다.

어 그렇다면, HTTPS는 TCP와 함께 동작하는데, 3-way handshake는 안하나요???

한다. 3-way 하고 나서, SSL Handshake가 이루어진다.

그럼 이제 SSL Handshake를 살펴보자.

  • Client Hello

    Client -> Server
    SSL Version, Client가 사용할 수 있는 Cipher Suite (암호화 방식), Client Nonce(= Random, Replay Attack을 방지하기 위한 난수 값) 들에 대한 정보가 있다.

Cipher Suite 구조 : Protocol_Key교환 방식_암호화 방식_WITH_Block 암호화 방식_Block 암호 공유 방식_Hash함수

  • Server Hello

    Server -> Client
    Server가 자신의 Version, Client가 보낸 Cipher Suite 중 Server가 선택한 방식이 전달된다. [TLS_RSA_WITH_RC4_128_SHA]

이 과정에 있어서, client certificate request는 선택적으로 포함된다.

  • Certificate, Server Hello Done

    Server -> Client

Certificate, 즉 인증서를 Server가 Client에게 전달한다. 이 인증서는 CA의 비공개 Key(=개인 Key)로 암호화되어 있으니, CA의 공개 Key로 복호화하여 Server의 신뢰성을 검증한다.
이 과정에서 Server Key Exchange는 포함 될 수도, 아닐 수도 있다. 만약 인증서 내부에 Server의 공개 Key가 있으면 생략되는 것. 만약 없다면 존재할 것이다.

  • Client Key Exchange, Change Cipher Spec, Encrypted Handshake Message

    Client -> Server
    대칭 Key를 Client가 SSL 인증서를 통해 전달된 Server의 공개 Key로 암호화하여 전달한다.
  • Change Cipher Spec, Encrypted Handshake Message

    Server -> Client
    서로 통신하기 위해 필요한 준비를 다 마쳤음을 의미한다.

http://www.ktword.co.kr/word/abbr_view.php?m_temp1=1957&id=831&nav=2

https://datatracker.ietf.org/doc/html/rfc6101

0개의 댓글