Transport-layer security (TLS)
http 등 응용 계층 등에서 보안이 필요하다. 이런 경우 응용단 하나를 만들 때 암호화 기능 하나씩 생성하면 필요성이 만족된다. 하지만, 표준이 존재하면 각자 암호화를 하는 수고를 덜 수 있는데, 전송 계층에서 사용할 수 있는 보안 표준이 TLS이다.
전송 계층에서의 보안은 여러 가지 응용의 보안을 지원하는데,
온라인 웹에서는 은행, 상거래, 이메일 등에도 구현이 되어 있다.
암호화는 보통 대칭키를 사용한다.
대칭키로 서로 대응되는 암호화 키와 복호화 키를 사용해 암호화를 진행한다.
대칭키를 통해 암호화를 진행하여 데이터의 기밀성이 지켜져야 한다.
암호화가 만족되기 위해서는 데이터에 대해 무결성(integrity)이 지켜져야 한다.
무결성이란 데이터가 위조되거나 변조되지 않아야 하며 결점이 없어야 한다.
또, 보안에서 중요요소는 해당 서버가 진짜인지를 보장해주기 위한 인증(authentication)이다.
최근에는 블록체인에서 사용자의 50%가 해당 서버가 진짜임을 보증하면 신뢰하는 방식을 사용하기도 한다.
SSL(Secure Socket Layer, 소켓 프로그래밍 시) 3.0 -> IETF TLS 1.0
TLS 1.2 -> TLS 1.3 [RFC 8846]
따라서 TLS의 핵심기능은 암호화, 인증, 무결성이다.
TLS 기능
TLS의 기능은 API를 통해 제공된다.
TLS는 TLS 버전/암호집합을 결정하고 서버 인증서 이용 시 신원을 인증하고 세션키를 생성하는 기능을 제공한다.
이때, TCP + TLS + HTTP를 HTTPS라고 하며 443번 포트를 주로 이용한다.
위 사진은 우리가 익숙하게 많이 봤던 HTTP/2와 HTTP/3의 모습이다.
HTTP/2는 TLS 1.2와 TLS 1.3을 모두 사용한다.
HTTP/3은 TLS 1.3을 사용하며 그림에서 TLS 1.3 아래에서 TCP에서 제공하는 에러 컨트롤과 혼잡 제어 기능이 존재한다.
Network Security
네트워크 보안에서는 아래와 같은 네 가지 기능을 요구한다.
- confidentiality(기밀성)
암호화된 데이터에 대해서는 송신자와 수신자만 해당 데이터를 '이해'할 수 있어야 한다.
송신자는 데이터를 암호화하고, 수신자는 데이터를 복호화한다.
- authentication(인증)
일반적으로는 서버, 즉 수신자만 인증을 한다. 하지만 은행과 같은 사이트에서는 송신자와 수신자 모두 인증한다.
- message integrity(무결성)
송신자가 보낸 데이터는 수신자가 수신한 후 확인한 데이터와 다름이 없어야 한다.
- access and availability(가용성)
암호화된 데이터에 대해서 항상 접근이 가능해야 한다.
접근이 가능할 때와 불가능할 때가 존재해서는 안 된다.
Needed
- handshake
TLS도 TCP와 마찬가지로 handshake과정을 거친다.
보통 TCP handshake 이후에 진행되며 이 과정에서 인증서와 개인 키를 이용하여 서로를 인증하고, shared secret를 교환하거나 생성한다.
shared secret은 암호화/복호화 시 필요한 키를 그대로 전송하면 안 되기 때문에 키를 계산할 수 있는 알고리즘이다.
- key derivation
handshake 시 공유한 shared secret를 통해 키 집합을 생성한다.
- data transfer
stream data transfer: 데이터를 일련의 레코드로 만든다.
- connection closure
안전하게 연결을 종료하기 위한 특별한 메세지이다.
연결을 생성할 때의 모습을 그림으로 나타낸 것이다.
윗 부분에서 TCP의 handshake를 통해 연결을 생성하였다.
남자는 여자로부터 받은 인증서를 통해 해당 사용자를 인증한 후 master secret key(MS)를 전송한다. 이때, MS는 TLS 세션의 모든 키를 생성할 때 사용된다.
하지만 위의 과정은 TCP 연결을 포함하여 3RTT라는 긴 시간이 걸린다.
따라서 TLS 1.3에서 시간을 단축하여 조금 더 빨라졌다.
(여담으로 TLS 1.3은 TLS 1.2의 성능 개선을 목적으로 개발되었다.)
cryptographic keys
두 개 이상의 암호화를 진행할 때 동일한 키로 암호화를 진행하면 안 된다.
따라서 인증할 때에는 message authentication code(MAC)를 사용하고 메세지 암호화 시에는 서로 다른 키를 사용하여 진행해야 한다.
MAC는 메세지 인증에 쓰이는 작은 코드로 비밀 키를 입력받아 임의의 길이 메세지를 인증해준다.
인증 시 사용하는 키는 4개로 아래와 같다.
- Kc : 클라이언트에서 서버로 보내는 데이터의 암호화 키(기밀성)
- Mc : 클라이언트에서 서버로 보내는 데이터의 MAC 키(무결성)
- Ks : 서버에서 클라이언트로 보내는 데이터의 암호화 키(기밀성)
- Ms : 서버에서 클라이언트로 전송되는 데이터의 MAC 키(무결성)
encrypting data
암호화된 데이터에 대해 전체를 계산하지 않고 일부를 계산한 후 해시함수에 넣었을 때 전송 전과 수신 후의 일부 값이 동일하다면 해당 데이터는 무결성이 보장된다고 판단하는데, 이는 해시 알고리즘의 일부라고 할 수 있다.
메세지의 길이가 긴 경우 이 메세지가 얼마나 긴지, 언제 수신이 끝나는지 모르기 때문에 우리는 데이터를 레코드 단위로 나누어 계산한다.
이때 TCP는 바이트 단위로 메세지를 전송하기 때문에 해시 함수를 사용하기 위해 바이트 스트림을 레코드 단위로 나눈다.
각 레코드는 Mc를 이용하여 만들어진 MAC를 포함하며, 대칭 키 Kc를 통해 암호화되어 TCP로 전달된다.
TCP 연결 데이터 공격
우리가 TCP 연결 시 전송하는 데이터를 보호하는 이유는 다음과 같이 TCP 연결에 대한 데이터를 공격하기 때문이다.
- re-ordering
데이터 전송 시 나와 공유기, 공유기와 서버의 경로를 통과한다.
이때, 공유기는 내가 전송한 데이터를 복호화하여 내용을 확인할 수 있다.
이러한 TCP 세그먼트를 가로채고 데이터의 내용을 변경한 후 TCP 헤더의 시퀀스 번호를 조작하여 세그먼트를 재정렬한다.
- replay
전송되고 있는 패킷을 중간에서 캡처한 후 캡처된 인증정보들을 그대로 재연하여 사이트에 인증한다.
위와 같은 공격은 TCP 패킷이 암호화 되지 않았을 때 발생한다.
그렇다면 어떻게 공격을 막을 수 있을까?
- TLS sequence number
re-ordering의 대비책으로 TLS 패킷에 번호를 순서대로 메겨 수신 시 해당 순서가 맞지 않는 패킷을 버리는 방법이다.
- nonce
TLS 패킷에 랜덤한 번호를 생성한 후 생성된 번호를 한 번 사용하고 버리는 것이다.
따라서 replay 시 패킷을 캡처하더라도 캡처된 패킷에 대한 번호를 그대로 다시 전송하면, 해당 번호는 유효하지 않은 번호가 되어 패킷이 버려지게 된다.
connection close
공격자는 TCP 연결 종료 패킷을 위조하여 강제로 연결을 종료시킬 수도 있다.
강제로 연결을 종료하는 것이 위험한 이유는 비밀번호 변경과 같은 변경 사항을 서버에서 커밋하기 전에 연결이 끊기면 사용자는 잘못된 상태를 가질 수 있기 때문이다.
이러한 강제 연결 종료를 위해 레코드에 타입을 지정해 준 다음, 타입 중 하나로 종료를 넣는 것이다.
일반 데이터의 경우 0, 종료 레코드인 경우 1을 넣어준다.
그러면 MAC는 이제부터 데이터와 타입, 시퀀스 숫자를 통해 계산된다.
우리는 TLS의 버전을 합의해야 한다.
우리는 TLS와 SSL을 혼용하여 사용한다. 사실 SSL에서 부가적인 기능을 추가하다보니 더 좋은 성능을 보며 TLS가 탄생하였다. 현재는 TLS가 표준이지만 라이브러리를 가져와서 구현할 때에 SSL을 가져와서 사용하기도 한다.
TLS 개요
개요
TLS에서는 프로토콜의 버전을 동의하고, 암호화 알고리즘을 선택하고 인증서를 교환 및 검증하는 과정과 암호키를 생성하는 작업이 수행된다.
암호화 모음 (Cipher Suite)
- 키 교환 프로토콜: Diffe-Hellman(DH)
DH 알고리즘은 상대방의 공개키와 나의 개인키를 이용하여 계산을 하면 비밀키가 나오게 되는 알고리즘이다. 이후, 데이터를 송수신할 때 계산된 비밀키를 통해 암호화를 진행한다.
- 인증: RSA(공개키)
- 암호화: AES(대칭키)
- 무결성: SHA256(해시)
SHA256는 메세지나 데이터의 무결성 검증에 사용되는 암호화 해싱 알고리즘(Secure Hash Algorithm)이다. 이 알고리즘은 어떤 값을 입력으로 받아도 256비트의 고정된 결과값을 출력한다. 아주 작은 확률로 서로 다른 입력을 넣었을 때 동일한 결과가 나오기도 한다.(충돌) 이는 결과값의 형식이 정해져 있기 때문이다.
TLS Handshake 프로토콜
TLS handshake 프로토콜은 위 사진과 같다.
- Client Hello
Client Hello에서는 TLS의 버전과 사용 가능한 암호화의 종류에 대해 알려준다.
- Server Hello
암호화 종류
- Certification
인증서
- Server Hello
- Client Key Exchange
premaster secret 생성 후 서버의 공인 키로 암호화 후 전송
SSL/TLS 인증서 (certification)
웹 사이트에서 인증서를 발급 받을 때에는 웹 서버에 SSL/TLS를 설치한다.
이때, 인증서는 certification authority(CA)와 같은 신뢰할 수 있는 기관에서 발급한다. TLS 통신을 하기 위해서는 CA를 통해 인증서를 발급 받아야 한다.
CA는 엄격하게 공인된 기업으로 자체적인 공개키와 비밀키를 가지고 있으며 이 비밀키는 절대로 누설되어서는 안 된다.
이때 하나의 회사로부터 모든 서버에서 인증서를 일일히 다 다운 받으면 비효율적이기 때문에 DNS처럼 인증서를 배분하여 각자 가까운 지점으로부터 다운로드 받는다. 따라서 이러한 인증서들이 트리처럼 체인으로 묶여있다.
이러한 인증서는 우리도 확인할 수 있다. 웹 서버에서는 인증서가 필수이다.
위 사진은 TLS handshake의 과정을 도식화한 것이다.
1. Client Hello
- Supported chipers: 클라이언트가 지원하는 암호화 방식의 종류이다. (대칭키 암호화 시스템 + 공개키 암호화 시스템 + 해시함수)
- Random Number: 클라이언트가 생성한 난수이다. 대칭키 생성 시 사용한다.
- Session ID
TLS 인증을 하는 과정은 시간이 소요되는 작업이기 때문에 매 연결마다 handshake를 진행하는 것은 비효율적이다. 따라서 최초 연결 시에만 정석으로 handshake를 진행하고, 그 뒤부터는 간소하게 진행하기 위해 사용한다.
최초 등록 시에는 서버에서 Session ID를 발급해주는데 클라이언트는 이 아이디를 로컬에 저장한다. 이후 다시 이 서버와 handshake를 진행할 때에 Session ID를 전송한다. 이 방법을 사용하면 서버 인증서 확인/암호화 방법 선정/대칭키 교환의 작업이 필요하지 않게되어 100ms의 시간이 절약된다.
- SNI(Server Name Idication)
서버의 이름을 명시하는 곳이다. 최근에는 IP 주소 하나에 여러 개의 도메인이 할당되어 있다. 그런데 이러한 인증서는 모든 도메인마다 발급해줄 수 없기 때문에 현재 가고 있는 도메인에 대한 SNI를 패킷에 명시해준다.
2. Server Hello
3. Server Certification
- Selected cipher: 선택한 암호화 방식이 무엇인지 알려준다.
서버에서 클라이언트에게 인증서를 보낸다. 이후 서버는 자체적으로 생성한 난수와 이전에 주고 받은 난수를 조합하여 pre-master secret 키를 생성한다. 생성된 pre-master secret은 서버의 공개키로 암호화 진행 후 클라이언트로 송신한다.
4. Server Hello Done
서버가 클라이언트에게 보낼 수 있는 메세지를 모두 보냈다는 의미이다.
5. Client Key Exchange Message
클라이언트가 만들어 둔 pre-master secret을 서버의 공개키로 암호화하여 서버에게 전송한다.
6. Key Generate
이전에 공유한 pre-master secret를 통해 키를 생성한다.
7. Cipher Spec. Exchange
8. Finshed
TLS: 1.3 cipher suite (암호화 세트)
cipher suite는 키 생성, 암호화, MAC, 디지털 서명과 같은 알고리즘이다.
TLS 1.3에서는 TLS 1.2보다 선택할 수 있는 암호화 알고리즘의 개수가 작은데 그 개수는 37개에서 5개로 줄었다.
키를 교환할 때 RSA 알고리즘으로 공개키를 교환하는 것이 아닌, Diffie-Hellman(DH)를 필요로 한다.
데이터를 직렬로 암호화하지 않고, 암호화와 인증 알고리즘을 결합하여 인증된 암호화라고도 하며 AES 인증 기반이다.
HMAC는 SHA(256 or 284) 해시 알고리즘을 사용한다.
TLS 1.3 Handshake: 1 RTT
앞서 언급한 TLS 1.2의 handshake 과정이 많아 3 RTT라는 시간이 필요했다. TLS 1.3에서 어떻게 이 시간을 줄였는지 확인해보자.
1. Client Hello
연결될 프로토콜을 추측해보고 사용 가능한 cipher suite를 전송한다.
2. Server Hello
선택한 cipher suite를 전송하고, 서버의 서명된 인증서를 보낸다.
3. Client
서버의 인증서를 확인하고, 키를 생성한다. 그리고 이제부터 HTTP 요청과 같은 응용 요청을 생성할 수 있다.
TLS 1.3 Handshake: 0 RTT
초기의 hello msg에는 암호화된 응용 데이터를 포함하고 있다.
클라이언트와 서버는 이전 연결을 재개하는데, 이전 연결에서 resumption master secret을 이용하여 어플리케이션 데이터를 암호화하였다?
replay 공격에 취약하지만 서버 상태를 수정하지 않는 GET 또는 클라이언트의 요청을 가져오는 것에 대해서는 덜 위험하다.
따라서 TLS 1.3은 TLS 1.2의 성능을 개선하여 위 사진과 같이 RTT의 개수를 줄여준다.
출처 및 참고
https://ko.wikipedia.org/wiki/%EB%A9%94%EC%8B%9C%EC%A7%80_%EC%9D%B8%EC%A6%9D_%EC%BD%94%EB%93%9C
https://velog.io/@dltmdrl1244/%EB%84%A4%ED%8A%B8%EC%9B%8C%ED%81%AC-8-5.-TLS
'Computer Science > 컴퓨터네트워크(ComNet)' 카테고리의 다른 글
| [컴네/CN] 암호통신: 무결성 (1) | 2023.12.09 |
|---|---|
| [컴네/CN] 암호통신: 대칭키, 공개키 (1) | 2023.12.09 |
| [컴네/CN] IP Routing: BGP (2) | 2023.12.07 |
| [컴네/CN] IP Routing: RIP, OSPF (2) | 2023.12.07 |
| [컴네/CN] IP Routing (1) | 2023.12.07 |