TLS 프로토콜

SSL -> TLS로 버전이 올라감에 따라 명칭이 바뀌었다. 

2015년까지는 SSL을 썼으나 RFC라는 통신 네트워크 표준화 기관에서 TLS가 나오다가 1.2에서 통합되었다고 보면 된다.

 

현재 TLS1.2를 가장 많이 사용하고 1.3도 사용하곤 한다. 

 

TLS는 4계층 보안으로 end hosts간의 기밀성, 무결성, 인증 제공을 목표로 한다. 

=> 기밀성(대칭키), 무결성(MAC), 인증(공개키)

 

쓰이는 곳을 보면 Https, voip, CoAP, MQTT도 Tls를 사용한다. 

또한 TLS는 TCP에 대한 보안이라 생각하면 된다. 

UDP에 대한 보안은 DTLS로 TLS를 살짝 변형한 것이다. 이는 여기서 다루지 않는다. 

TLS는 총 4개의 프로토콜로 이루어져있다. 

하지만 중요한 것은 Handshaking, Record Protocol이므로 이 두가지를 다루도록 한다.

 

HandShake Protocol은 상호간의 인증, 어떤 TLS버전인지 등을 교환한다.

이때 세부적인 프로토콜은 HandShake Protocol, Change Cipher Spec protocol, Alert Protocol이다.

동작 과정은 위와 같다.

1) Client가 먼저 Hello를 보낸다. (=본인이 device TLS버전, 지원하는 암호화 알고리즘 포함)

2) Server Hello(제공하는 암호화 세트, 서버 인증서, 서버 공개키, +옵션(Client의 공개키, 필요하면 요청)

3) Client는 서버의 인증서 검증

4) Client는 인증서를 보낸다.

5) Server는 Client를 인증한다.

6) 이까지 진행한 후 추가로 암호화 방법을 바꾸고 싶을때 Change Cipher Spec을 활용한다. Server, Client아무나 가능

 

이까지의 과정을 보면..

TLS버전, Client Random(난수 값), Client 암호화 방법 등이 포함되어 간다. 

여기서 보면 0X16뒤에 0303이 TLS 1.2를 의미한다.

이건 CipherSute인데 키 교환 방법, 인증 방법, 암호화 방법 등에 대한 알고리즘들을 무엇을 쓸것인지 기술한다.

Hello Verify Request는 Client Hello를 받은 Server가 바로 보내오는 것이다.

TLS와 DTLS의 차이가 바로 이부분이다.

UDP의 경우에 이 단계를 진행하는데 Server는 Client의 응답으로 stateless한 쿠키를 보내어 Ddos공격을 막을수 있다.

또한 연결이 불안정하기 때문에 verify과정을 거치는게 효율적이다. 

서버가 보내는 내용도 비슷하다.

자신의 TLS프로토콜 버전을 제공하고 난수, 사용할 Session ID, 암호화 알고리즘을 골라서 제공한다.

이후 서버의 인증서를 보내게 된다.

이는 키교환을 위한것인데 인증서를 안쓴다고 하면 Preshared Key를 활용해서 키를 교환한다.

이렇게 키를 주고받고 나면 Serve Key Exchange단계에서 디피헬먼과 같은 과정으로 키를 교환한다.

 

* RTT : TLS 1.3이 새롭게 추가한 모드로 암호화 알고리즘, 키의 교환, 인증서 서명 방식을 합의하기 위한 과정이다. 이 과정은 PSK라 부르는 키를 하나 만들어 공유한다. 이를 암호화된 통신으로 주고받으면 클라이언트가 PSK와 에플리케이셔 데이터를 포함시켜 보낸다

 

데이터의 무결성을 보장하고 암호화 하기 위해서는 Record Protocol을 활용한다.

이는 전체 데이터를 분할하여 분할 한 부분에 대한 MAC값을 결합한다.

이때 암호화 한것에 MAC값을 붙이는 것과 MAC값을 붙인 것을 암호화 하는 방법이 있는데 

두 번째 방법이 훨씬 안전하다.

여기서는 MAC값을 붙인 값을 암호화 하여 보내게 된다.