HTTP/HTTPS?

우선 SSL/TLS를 어디에 왜 사용하는지 알기 위해 HTTP와 HTTPS는 무엇인지, 무슨 차이점이 있는지 알아야 한다.

HTTP(Hypertext Transfer Protocol)는 말 그대로 HTML을 전송하기 위한 통신규약을 의미한다.
HTTPS에서 마지막의 S는 Over Secure Socket Layer의 약자로 Secure라는 말의 말을 통해서 알수 있듯이 보안이 강화된 HTTP라는 것을 알 수 있다.

HTTP는 암호화되지 않은 방법(평문)으로 데이터를 전송하기 때문에 서버와 클라이언트가 주고 받는 메시지를 감청하거나 변조하기 매우 쉽다.

HTTPS는 암호화를 한 뒤 암호화 터널(SSL/TLS Layer)을 통해 데이터를 주고받기 때문에 해커가 감청하더라도 변조하거나 가져다 쓰기 힘들다.

그렇다면 이 HTTPS 통신은 어떻게 이루어지는지 알아보자!

SSL/TLS

SSL/TLS란?

결론부터 말하자면

SSL(Secure Socket Layer)과 TLS(Transport Layer Security)는 같은 말이다.

SSL/TLS는 웹 브라우저와 서버(Client - Server) 양단의 TCP 기반 통신 시 응용 계층 및 TCP 전송계층 사이에서 보안 채널 형성 및 암호화 하는 보안 프로토콜이다.

Netscape Communications라는 회사에서 WWW(World Wide Web)의 통신을 안전하게 유지하는 것을 목적으로 SSL이 발명 되었고, 이것이 점차 폭넓게 사용되다가 표준화 기구인 IETF의 관리로 변경되면서 TLS라는 이름으로 바뀌었다.

TLS 1.0은 SSL 3.0을 계승한다. SSL은 보안의 문제가 많아 모든 버전의 SSL은 더 이상 사용되지 않고 TLS를 사용하지만 TLS라는 이름보다 SSL이라는 이름이 훨씬 많이 사용된다.

SSL vs TLS 주요 차이점

SSL이 이전에 나오고, TLS가 그 다음 버전인 만큼 차이점이 몇 개 있다. 그것에 대해 정리해보자.

	SSL(Secure Socket Layer)	TLS(Transport Layer Security)
버전 기록	SSL은 1.0, 2.0, 3.0의 버전이 있지만 TLS로 대체되어서 사용되지 않는다.	SSL의 업그레이드 된 버전이다. 버전에는 1.0, 1.1, 1.2, 1.3 이 있다.
사용	모든 SSL 버전이 더 이상 사용되지 않는다.	TLS 버전 1.2, 1.3 이 사용되고 있다.
알림 메시지	두 가지 유형의 알림 메시지만 있다. (경고, 치명적) 알림 메시지는 암호화 되지 않는다.	메시지가 암호화되며 더 다양하다.
메시지 인증	MAC(Message Authentication Code) 을 사용한다.	MAC보다 더 강화된 HMAC(Hash Message Authentication Code) 를 사용한다.
암호 그룹	알려진 보안 취약점이 있는 이전 알고리즘을 지원한다.	고급 암호화 알고리즘을 사용한다.
HandShake	복잡하고 느리다.	단계가 적고 연결 속도가 빠르다.

• 메시지 인증 코드(MAC) : 데이터가 변조(수정, 삭제, 삽입 등) 되었는지를 검증할 수 있도록 데이터에 덧 붙이는 코드이다. SSL/TLS에서 통신 내용의 인증과 무결성 확인을 위해 사용하고 있다.

프로토콜 구조

SSL/TLS 프로토콜은 Transport Layer(4 Layer)와 Application Layer(7 Layer) 사이에 따로 SSL/TLS 계층을 두어 동작하게 된다.

• HandShake : 양쪽 간에 연결을 설정할 때 보안 협상을 위한 프로토콜
• Change Cipher Spec : 보안 파라미터를 변경하거나 적용할 때 사용. 예를들어 대칭키 알고리즘을 변경할 때 이 프로토콜 사용
• Alert : 오류를 전송할 때 사용되는 프로토콜
• Application Data : 실제 데이터가 전송될 때 사용되는 프로토콜
• Record : 협상된 보안 파라미터를 이용하여 암 복호화 무결성 등을 수행하는 프로토콜이다.

Cipher Suite

SSL/TLS 암호 통신을 하는 데 사용되는 암호 알고리즘 집합을 의미하며, 3가지 종류의 알고리즘을 포함하고 있다.

Server와 Client가 어떤 Cipher Suite를 사용하여 통신할 지 정할 때 사용한다.
네트워크의 패킷을 캡쳐하는 Wireshark 라는 툴을 이용하여 Cipher Suite를 캡쳐해보았다.

잘 보면
Cipher Suite : TLS_AES_128_GCM_SHA256
Cipher Suite : TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
과 같이 Cipher Suite가 나열되어 있는 것을 확인할 수 있다.

_(Under bar) 를 기준으로 각 상태에 따른 암호 알고리즘을 나타내는데

TLS 프로토콜을 사용하며, 키 교환 방식은 ECDHE, 인증 알고리즘은 RSA, 대칭 알고리즘으로 AES 암호의 길이는 128bit, 블록 암호 운용 모드는 GCM, HMAC용 해시 알고리즘은 SHA-256 를 사용한다는 말이다.

• 프로토콜 : 프로토콜 종류를 나타낸다.
• 키 교환 알고리즘 : 암호 통신 시 사용하는 대칭 암호키를 교환하는 알고리즘
• 인증 알고리즘 : 키를 교환할 상대방이 교부한 인증서가 정말 내가 접속하고자 하는 상대방이 맞는지 확인하는 알고리즘
• 암호화 알고리즘 : 주고 받는 실질적인 데이터를 암호화 할 때 사용하는 대칭키 알고리즘
• Message Authentication Code(MAC) Algorithm : 전달된 message의 무결성(Integrity)와 인증(Authentication)을 위해 사용되는 알고리즘

TLS 1.2 통신 프로세스

가장 많이 사용되고 있는 TLS 1.2를 기준으로 통신 프로세스를 정리해보겠다.

프로세스는 크게 HandShake(연결수립) - Session(전송) - Session 종료 순으로 일어난다.

이 과정은 은밀하게 일어나기 때문에 사용자에게 노출되지 않는다.

패킷캡쳐 Tool - WireShark
패킷 캡쳐를 할때 네트워크 캡쳐 툴인 WireShark를 사용하였다.

WireShark

HandShake(연결수립)

TLS 1.2 HandShake(연결수립) 과정
TLS 1.2 의 HandShake 과정은 총 10단계로 구성된다. 이 과정에서 암호화 방식, 키 값, 공개키 등을 교환한다.

0. TCP HandShke

일반 HTTP 연결할 때의 TCP HandShake와 동일하다.
TCP Handshake를 통해 클라이언트와 서버는 초기 연결을 수립하고 서로에 대한 확인을 할 수 있다. 이를 통해 데이터의 신뢰성을 보장하고 중간에 데이터가 유실되거나 변조되는 것을 방지할 수 있다.

• SYN(Synchronize Sequence Number) : 연결 설정. Sequence Number를 랜덤으로 설정하여 Connection을 생성할 때 사용하는 FLAG이다.
• ACK(Acknowledgement) : 응답 확인. 패킷을 받았다는 것을 의미하는 FLAG이다.

1. Client에서 Sequence Number를 랜덤으로 생성하여 Server로 접속을 요청하는 SYN 패킷을 전송한다. Client는 요청을 보내고 나면 SYN-SENT 상태로 변하게 된다.
2. 언제든지 Client의 요청을 받을 준비가 되어있는 Listen 상태의 Server에서는 Client로부터 온 SYN 패킷을 확인하고 ACK 패킷과 SYN 패킷을 함께 보낸다. Server는 SYN-RECEIVED 상태가 된다.
3. Client 에서는 Server의 SYN+ACK 패킷을 확인하고 응답을 보낸다. 그와 동시에 ESTABLISHED 라는 연결 성립이라는 상태가 된다.
4. 3번의 Client 응답을 받은 Server도 ESTABLISHED 상태가 된다.

1. Client Hello

Client측에서 Hello 메시지로 Server에게 기본적인 정보를 송신한다.

• Random : 나중에 Client와 Server의 랜덤 값을 조합/해시하여 대칭키 생성 시 Salt 역할을 수행한다.
• Session ID : TLS 통신에서 HandShake를 하는 과정은 시간이 많이 소요되기 때문에 매번 TLS 통신을 할 때마다 HandShake 과정을 반복하게 된다면 시간이 너무 많이 소요되고 비효율적이기 때문에 사용한다. 시간 상 100ms 정도 절약된다.
  Session ID는 최초 연결 시 Server Hello 과정에서 Server에서 전달 받는다.
• Cipher Suite : Client/Server가 각각 지원하는 암호화 방식이 다를 수 있기 때문에 어떤 암호화 방식으로 통신할 지 협상을 해야한다. Client(Browser)에 저장되어 지원되고 있는 암호화 방식 List를 Server에게 전달한다.
• Protocol Version : 프로토콜 버전이 다를 경우 HandShake 방식도 완전히 다를 뿐더러, 보안 업데이트로 인해 지원하는 암호화 방식도 다를 수 있기 때문에 Protocol버전도 맞아야 한다.

패킷 캡쳐 - Client Hello

2. Server Hello, Certificate, Server Key Exchange

Client의 Client Hello 메시지를 받은 Server에서도 Hello 메시지로 기본적인 정보를 수신한다.

• Random : 나중에 Client와 Server의 랜덤 값을 조합/해시하여 대칭키 생성 시 Salt 역할을 수행한다.
• Cipher Suite : Client가 보낸 암호화 방식 리스트 중 서버가 사용 가능한 암호화 방식을 선택하여 보낸다.
• Certificate : Server의 인증서를 Client에게 보낸다. 필요에 따라 CA의 인증서도 함께 전송한다.
  Server Key Exchange : SSL 인증서 내부에 공개키가 없다면 해당 공개키를 서버가 직접 전달해주는 것을 의미한다. SSL 인증서 내부에 있을 경우 Server Key Exchange는 생략된다.
  (많이 사용되는 키 교환 알고리즘 : Diffie-Hellman, RSA 등)

패킷 캡쳐 - Server Hello

패킷 캡쳐 - Certificate

패킷 캡쳐 - Server Key Exchange

3. Client Key Exchange, Change Cipher Spec

대칭키(비밀키, 실제 주고받는 데이터를 암호화 하는 Key)를 Client가 생성하여 SSL 인증서 내부에서 추출한 Server의 공개키를 이용하여 암호화 한 후 Server에게 전달한다. 여기서 전달된 대칭키가 바로 SSL HandShake의 목적이자 데이터를 암호화 할 대칭키(비밀키)이다.

대칭키 생성 정리

Client와 Server는 속도는 느리지만 안전하게 데이터를 주고받을 수 있는 공개키 방식으로 대칭키를 암호화 하고, 실제 데이터를 주고 받을때는 대칭키를 이용해서 데이터를 주고받는다.

1. pre master secret 키 생성

• Client Hello 에서 주고받았던 Random Data와, Server Hello 에서 주고받았던 Random Data를 조합하여 pre master secret 이라는 대칭키를 생성한다.

2. pre master secret 키를 Client와 Server 가 각각 일련의 과정을 거쳐 master secret 값으로 변환

3. master secret 값을 Client와 Server의 비밀키로 복호화 하여 Session Key 생성

• 암호화 된 정보는 상대방에게 전송될 것이고, 상대방도 Session Key 값을 알고 있기 때문에 암호를 복호화 할 수 있다.

패킷 캡쳐 - Client Key Exchange

패킷 캡쳐 - Change Cipher Spec

Session(전송)

Session은 실제로 Client와 Server가 데이터를 주고 받는 단계이다.
HandShake 과정에서 생성했던 Session Key 를 이용하여 대칭키 방식으로 데이터를 주고 받는다.
Client와 Server 둘 다 Session Key값을 알고 있기 때문에 데이터를 복호화 할 수 있다.

패킷 캡쳐 - Application Data
Session 단계에서 Client와 Server가 데이터를 주고 받을 때 Application Data라는 패킷을 통해 주고받아진다.

Session 종료

데이터 전송이 끝나면 SSL/TLS 통신이 끝났음을 서로에게 알려준다. 이 때 통신에서 사용했던 대칭키인 Session Key를 폐기한다.

TLS 1.2 에서 세션을 종료할 때 TCP 종료과정과는 다르게 종료 과정을 나타내는 메시지들을 교환하여 2 way HandShake 과정으로 안전하게 종료한다.

• Client Hello : Client가 종료하고자 하는 의사를 나타내기 위해 요청 메시지를 생성하고 서버에 전송한다.
• Server Hello : 종료 응답을 포함하여 응답한다.

보통이라면 이 두 과정(Client Hello, Server Hello)으로 TLS1.2의 세션이 종료되며 모든 리소스 들이 정리된다.

• S-Alert : 만약 종료 요청(C→S)이 수락되지 않거나 실패할 경우 Alert 메시지를 사용하여 클라이언트에게 이유를 알린다.
• C-Alert : 응답 및 경고 메시지를 확인하고 필요한 경우 Alert 메시지를 사용하여 서버에게 종료 확인을 보낸다.

TLS 1.3 통신 프로세스

보안 취약점 문제나 여러가지 편리성을 위해 TLS 1.3으로 넘어가고 있는 추세이니 TLS 1.3 통신 프로세스도 간단하게 정리해보겠다.
우선, TLS1.3의 장점은 아래와 같다.
TLS1.3의 장점

• 보안강화 : HandShake 단계에서 암호화 알고리즘 및 SSL/TLS 버전 등을 협상하는 과정에서 공격자가 개입하여 협상 내용을 보안에 취약하도록 변경하는 다운그레이드 공격 방어 기능 탑재, 취약 알고리즘 지원 중단
• 성능강화 : TLS1.2 버전에 비해 통신 속도 빠름
• 프라이버시 강화 : SNI(Server Name Indication) 서버 이름 표시를 암호화하여 사용자가 어떤 도메인으로 접속하는지도 알 수 없게 됨

1. TLS 1.2 handshake와 유사하게 client hello 메시지와 함께 시작된다. 클라이언트는 지원되는 Cipher Suite를 보내고 서버가 선택할 가능성이 큰 계약 프로토콜을 추측하며 클라이언트는 특정 키 프로토콜에 대한 키 공유를 전송하게 된다.

2. Client Hello 메시지에 대해 서버는 선택한 주요 계약 프로토콜로 응답한다. Server Hello 메시지는 서버키 공유로 구성되는데 해당 인증서 및 서버 완료 메시지가 표시되게 된다.

3. 클라이언트는 서버 인증서를 확인하고, 서버의 키 공유를 가지고 있기 때문에 키를 생성하고 Client Finished 메시지를 보낸다. 여기부터 데이터 암호화가 시작된다.