TLS

TCP/IP 네트워크를 사용하는 통신에 적용되며, 통신 과정에서 전송계층 종단간 보안과 데이터 무결성을 확보해준다.

TLS 암호화

TLS는 대칭 및 비대칭 암호화 조합을 사용하며,이는 데이터를 안전하게 전송할 때 성능과 보안간에 좋은 절충안을 제공하기 때문입니다.

대칭 암호화

대칭 암호화를 사용하면 데이터는 보낸 사람과받는 사람 모두에게 알려진 비밀 키로 암호화되고 해독됩니다. 대칭 암호화는 연산 속도면에서 효율적이지만 공통의 비밀 키를 안전한 방식으로 공유해야 할 필요가 있음을 의미합니다.

graph LR
	sender((송신자))
	reciver((수신자))
	sender-.-|1.대칭키 교환|reciver
	sender-->2.암호화
	2.암호화-->|대칭키|2.암호화
	2.암호화-.->|3.암호문 전송|4.복호화
	4.복호화-->|대칭키|4.복호화
	4.복호화-->reciver

비대칭 암호화

비대칭 암호화 혹은 공유키 방식은 출제자만이 알고 있는 특정한 종류의 정보(비밀 키) 없이는 매우 풀기 어려운 수학적 문제(공개 키)를 바탕으로 만들어진다. 키를 만드는 사람은 이 문제(공개 키)를 일반에 공개하고 특정한 정보(비밀 키)는 자신만이 알수 있도록 숨긴다. 그러면 어떤 사람이건 이 문제를 이용해 메시지를 암호화하면 키를 만든 사람만이 이 문제를 풀어 원래 메시지를 해독할 수 있다.

graph LR
	sender((송신자))
	reciver((수신자))
	reciver-.->|1.공개키, 개인키 생성|reciver
	공개키_저장소-.-|2.생성된 공개키 저장|reciver
	sender-.-|3.저장된 공개키 획득|공개키_저장소
	sender-->4.암호화
	4.암호화-->|공개키|4.암호화
	4.암호화-.->|5.암호문 전송|6.복호화
	6.복호화-->|개인키|6.복호화
	6.복호화-->reciver

CA

CA(Certificate Authority)는 X.509 표준을 준수하는 디지털 인증서를 발급하는 곳 입니다. 디지털 인증서는 인증서 소유자 (주체)의 공개 키를 인증하고 소유자는 인증서로 보호되는 도메인을 제어합니다. 따라서 신뢰할 수있는 제 3 자로서의 역할을 수행하여 클라이언트가 검증 된 서버에 연결한다는 보증을 제공합니다.

TLS Handshake

sequenceDiagram
    Client->>Server: 1) "client hello"
    Server->>Client: 2) "server hello"
    Server->>Client: 3) Server certificatie
    Client->>Server: 4) Client Key Exchage
    Client-->>Server: 5) Send client certificate
    Client->>Server: 7) Client "finished"
    Server->>Client: 9) Server "finished"
    loop encrypted
    Server->Client: Exchange Message
    end

1. 통신상태 확인을 위한 hello 메시지로 정보 교환, 클라이언트에서 사용 가능한 TLS 버전, 암호 모음 목록, 난수 및 압축 방법 목록, SNI 등이 포함합니다.
2. 통신상태 확인을 위한 hello 메시지로 정보 교환, 서버에서 사용할 TLS 버전, 암호 모음 목록, 난수 및 압축 방법 목록 등을 포함합니다.
3. 서버의 디지털 인증서를 유효기간과 발급된 서버가 올바른지 등을 확인합니다.
4. 클라이언트와 서버가 후속 메시지 데이터를 암호화하는 데 사용될 비밀 키를 계산할 수 있도록 하는 임의의 바이트 문자열을 보냅니다. 임의의 바이트 문자열 자체는 서버의 공개키로 암호화됩니다.
5. 만약 "클라이언트 인증서 요청"을 보낸 경우 클라이언트는 클라이언트의 디지털 인증서 또는 "디지털 인증서 경고 없음"과 함께 클라이언트의 개인 키로 암호화된 임의의 바이트 문자열을 보냅니다. 이 경고는 경고일 뿐이지만 일부 구현에서는 클라이언트 인증이 필수 일 경우 Handshake가 실패합니다.
6. 클라이언트의 인증서를 확인합니다.
7. Handshake의 클라이언트 부분이 완료되었음을 나타내는 "완료" 메시지를 비밀키로 암호화합니다.
8. Handshake의 서버 부분이 완료되었음을 나타내는 "완료" 메시지를 비밀키로 암호화합니다.
9. 서버와 클라이언트는 이제 공유 비밀키로 대칭적으로 암호화된 메시지를 교환할 수 있습니다.

SNI

SNI(Server Name Indication)는 TLS 프로토콜의 확장입니다. 클라이언트는 TLS Handshake의 SNI 항목을 사용하여 연결할 호스트 이름을 지정합니다. 이렇게 하면 서버(Apache, Nginx 또는 HAProxy와 같은 로드 밸런서)가 단일 IP 주소의 모든 인증서를 호스팅하는 동안 연결을 설정하는데 필요한 해당 개인 키를 선택할 수 있습니다.

SNI가 사용되면 서버의 hostname이 TLS Handshake 과정에 포함되며, HTTPS로 공유되는 IP 주소에 있더라도 고유한 TLS 인증서를 가질 수 있습니다.

ESNI

TLS Handshake 과정에서 SNI 정보를 교환할때 평문으로 전달되는 것을 암호화하여 중간자가 탈취할 수 없도록 하는 구조

HTTP 를 통한 통신

HTTPS 를 통한 암호화

ESNI 추가 암호화

참조

• https://www.internetsociety.org/deploy360/tls/basics/
• https://en.wikipedia.org/wiki/Server_Name_Indication
• https://www.globalsign.com/en/blog/what-is-server-name-indication/
• https://www.eff.org/deeplinks/2018/09/esni-privacy-protecting-upgrade-https
• https://datatracker.ietf.org/doc/draft-ietf-tls-esni/
• https://blog.cloudflare.com/encrypted-sni/
• https://blog.cloudflare.com/rfc-8446-aka-tls-1-3/