TLS/SSL

TLS와 SSL의 차이점

TLS는 Netscape가 개발한 SSL(Secure Sockets Layer)이라고 불리는 이전의 암호화 프로토콜의 업그레이드 버전이다.
TLS 버전 1.0은 SSL 버전 3.1로서 개발을 시작했지만 Netscape와 더 이상 연관이 없음을 명시하기 위해 발표 전에 프로토콜의 이름이 변경 되었다.

실제로 TLS와 SSL은 빈번히 혼용되고 있으며, SSL/TLS의 오픈소스 프로젝트 명은 OpenSSL이다.

SSL의 원리

SSL은 OSI 7계층 모델의 어느 한 계층에 속해서 동작하는 것이 아니라, 응용계층과 전송계층 사이에 독립적인 프로토콜 계층을 만들어서 동작하며,
응용 계층의 프로토콜들은 외부로 보내는 데이터를 TCP가 아닌 SSL에 보내게 되고, SSL은 받은 데이터를 암호화하여 TCP에 보내어 외부 인터넷으로 전달하게 된다.

https://www.lesstif.com/ws/ssl-tls-https-43843962.html

SSL은 TCP 위에서 Record Protocol을 통해 실질적인 보안서비스를 제공하고,

Handshake Protocol, Change Cipher Spec Protocol, Alert Protocol을 통해 SSL 동작에 관한 관리를 한다.

암호화 방식

TLS의 암호화 방식은 대칭 키과 비대칭 키 방식을 함께 사용하여 암호화를 제공한다.

대칭 키는 암복호화 키가 같기 때문에 데이터 전송 시 대칭 키를 해킹당할 위험이 있어 CS를 공부할 당시 당연히 비대칭키가 좋은 방식이라고 생각했었다.

하지만 비대칭 키 방식은 복잡한 암호화 원리로 이루어져 있어 많은 CPU 리소스를 소모한다.

그래서 비대칭 키 만을 이용한 통신에는 성능 저하가 우려되어 TLS에서는 이와 같은 방식을 채택하였다.

대칭 키 방식의 단점은 통신 시 해킹의 우려가 있다는 점 이었다.

이를 보완하기 위해 대칭 키 자체를 비대칭 키로 암호화 하여 키를 전달하고, 실제 통신은 대칭 키 방식으로 통신을 하는 것이다.

인증서

신뢰할 수 있는 통신은 암호화만을 통해서 해결할 수 있는 문제가 아니다.아무리 암호화가 잘 되어 송신하더라도 가짜 서버라면 문제가 생길 것 이다.통신 과정 중 통신하는 서버가 신뢰할 수 있는 서버인지확인하는 작업이 필요하다.이를 위해 사용하는 것이 인증서다.

CA (Certificate Authority)

인증서를 발급해 주는 기관으로, Root Certificate라고도 한다.

CA는 아무나 할 수 있는 것이 아니라 신뢰성이 공인된 기업들만 가능하다.

TLS 통신을 하려면 CA를 통해 인증서를 발급 받아야 한다.

CA는 인증서 발급 요청을 받게되면, 해당 요청자의 공개 키를 해시 알고리즘을 통해 Finger Print로 등록하고, CA의 개인 키로 암호화하여 인증서에 서명(Digital Signing)하여 발급해준다.

 

그렇다면 인증서에는 디지털 서명, 발급자 정보, 공개 키 등의 포함되어 있는데,

이 처럼 상위 인증 기관이 인증서에 포함된 공개 키를 상위 기관의 비밀키로 암호화하여 보증하는 것을 인증서 체인(Certificate Chain) 이라고 한다.

 

내가 Root CA에게 발급 받은 것이 아니더라도, 이 CA는 상위 CA로 체인을 통해 결국은 Root CA에게 인증을 받아 발급한 인증서라는 것이다.

 

서버 <-> 클라이언트 인증

이렇게 발급받은 인증서를 가지고 어떻게 인증을 하는 것 일까?

서버는 통신을 하고자하는 클라이언트에게 전달한다. 이 과정에서 전달된 인증서에 대한 무결성을 입증해야 하는데,

 

클라이언트는 CA 리스트(CA의 공캐 키도 함께)를 가지고 있으므로 이 인증서의 CA를 확인한다.

CA의 공개 키를 가지고 있기 때문에 이 공개키로 복호화한 디지털 서명의 해시 값과 공개 키를 해시한 값을 비교해 위조 여부를 판별 한다.

 

실습으로 확인해보자.

https://emn178.github.io/online-tools/sha256.html

위 사이트를 통해 특정 문자를 SHA256 알고리즘을 통해 해시할 수 있다.

 

만약 어떠한 CA로 부터 발급받은 인증서가 있다면 이 인증서를 SHA256과 같은 알고리즘을 통해 암호화 한다.

 

https://www.devglan.com/online-tools/rsa-encryption-decryption

위 사이트를 통해 RSA 암호화와 복호화를 실습 할 수 있다.

 

첫 번째로 임시 비대칭 키 쌍을 생성한다. 이를 통해 인증서의 무결성을 검사할 것이다.

 

왼쪽 상단부터 순서대로 hash 값을 개인 키를 통해 암호화 하고,

이 암문을 공개 키로 복호화 하면 평문인 hash 값이 나온다.

 

이 두개의 값을 비교하여 인증서가 무결한지 검사하는 것이다.

TLS 핸드셰이크

위 단계는 TLS 암호화의 기본 동작이지만, 위 내용의 무결성을 검증하기 위한 핸드셰이크 과정을 거치게 된다.

핸드셰이크는 클라이언트와 서버간의 메세지 교환이며, HTTPS 웹에 처음 커넥션할 때 진행된다.

핸드셰이크의 단계는 클라이언트와 서버에서 지원하는 암호화 알고리즘, 키 교환 알고리즘에 따라 달라진다.

https://www.alibabacloud.com/blog/analysis-of-tlsssl-handshake-failure-scenarios-on-alibaba-cloud_595800

TLS 통신을 대략적으로 살펴보면,

• 클라이언트와 서버는 헬로 메시지로 기본적인 정보를 송수신 (1, 2)
• 서버는 서버가 사용하는 SSL/TLS 인증서를 전달 (3, 4, 5)
• 클라이언트는 암호화 통신에 사용할 대칭키를 생성하고 사이를 서버에 전달(6). 이 과정을 키 교환(Key Exchange) 라고 하며 디피-헬만 키 교환(Diffie–Hellman key exchange) 또는 RSA 를 많이 사용.
• 클라이언트는 암호화 통신에 사용 가능한 암호 알고리즘과 해시 알고리즘 목록을 서버에 전달. (7, 8)
• 서버도 알고리즘 목록을 교환후 핸드셰이크가 종료되며 이제 클라이언트와 서버는 암호화 통신에 필요한 대칭키를 서로 보유.(9, 10)

이러한 핸드셰이크 과정은 TLS 버전, 암호화 알고리즘에 따라 달라질 수 있다.