TLS를 사용함으로써 발생하는 오버 헤드는 무엇입니까? 이상하게도 웹에서 검색을 수행하여 곧바로 대답을 찾을 수 없으므로 내용을 살펴 보겠습니다. TLS 핸드 셰이크에는 여러 가지 변형이 있지만 가장 일반적인 익명 클라이언트 및 인증된 서버 (브라우저에서 가장 많이 사용하는 연결) 를 기준으로 하겠습니다.
TLS 표준에 따른 핸드 셰이크는 다음과 같습니다.
Client Server ClientHello --------> ServerHello Certificate <-------- ServerHelloDone ClientKeyExchange [ChangeCipherSpec] Finished --------> [ChangeCipherSpec] <-------- Finished Application Data <-------> Application Data
계산에 영향을 미칠 수 있는 한 가지 사실은 대부분의 메시지가 가변적 이라는 것입니다. 변수의 정확한 값을 계산할 수 없지만 가변 필드에 대해 합리적인 평균 값을 취하면 오버 헤드에 대한 좋은 근사를 얻을 수 있습니다. 이제 각 메시지를 살펴보고 크기를 고려해 보겠습니다.
- ClientHello - 초기 클라이언트 hello 의 평균 크기는 약 160-170 바이트입니다. TLS ClientHello 확장 기능의 수 뿐만 아니라 클라이언트가 보낸 암호 집합 수에 따라 다릅니다. 세션이 재개되면 세션 ID 필드에 다른 32 바이트를 추가해야 합니다.
- ServerHello - 이 메시지는 ClientHello 보다 조금 더 정적이지만 TLS 확장으로 인해 여전히 가변적입니다. 평균 크기는 70 ~ 75 바이트입니다.
- 인증서 - 이 메시지는 서로 다른 서버간에 크기가 가장 큰 메시지입니다. 이 메시지는 서버의 인증서와 인증서 체인의 모든 중간 발급자 인증서 (루트 인증서 제외) 를 전달합니다. 인증서 크기는 사용 되는 매개 변수와 키에 따라 상당히 달라 지므로 인증서 당 평균 1500 바이트를 사용합니다 (자체 서명 된 인증서는 800 바이트 정도 될 수 있음). 다른 다양한 요소는 루트 인증서 까지의 인증서 체인 길이 입니다. 웹에 있는 것보다 보수적인 측면에서, 체인에 4 개의 인증서가 있다고 가정 해 봅시다. 전반적으로 이것은 이 메시지에 대해 약 6k 정도가 됩니다.
- ClientKeyExchange - 가장 널리 사용되는 사례인 RSA 서버 인증서를 다시 가정해 봅니다. 이것은 이 메시지의 크기인 130 바이트에 해당합니다.
- ChangeCipherSpec - 1 의 고정 크기 (기술적으로는 핸드 셰이크 메시지가 아님)
- Finished - SSLv3 이 사용되는지 TLS인지에 따라 크기는 각각 36 및 12 바이트로 상당히 다릅니다. 대부분의 구현은 요즘 TLSv1.0 을 지원합니다. 따라서 TLS를 사용한다고 가정하고 크기를 12 바이트로 가정합니다.
교환 된 각 메시지의 평균 크기가 계산 되었으므로 평균 핸드 셰이크 크기를 계산할 수 있습니다. 교환된 메시지에는 전송된 각 레코드 (5 바이트) 와 TLS 핸드 셰이크 헤더 (4 바이트) 에 대한 TLS 레코드 헤더가 있어야 한다는 사실을 명심해야합니다. 핸드 셰이크 다이어그램의 각 화살표가 TLS 레코드가 되도록 가장 일반적인 경우를 단순화 할 수 있으므로 합계 20 바이트로 4 레코드가 교환됩니다. 각 메시지는 핸드 셰이크 헤더 (ChangeCipherSpec 하나 제외) 를 가지므로 총 28 바이트의 핸드 셰이크 헤더를 7 번 가지고 있습니다.
새 TLS 세션을 설정하기위한 총 오버 헤드는 평균 약 6.5k 바이트 (20 + 28 + 170 + 75 + 6000 + 130 + 2 * 1 + 2 * 12 = 6449)가됩니다.
일단 설정된 TLS 세션도 다시 시작 할 수 있습니다. 세션 재개시 일부 메시지는 생략되고 핸드 셰이크는 다음과 같습니다.
Client Server ClientHello --------> ServerHello [ChangeCipherSpec] <-------- Finished [ChangeCipherSpec] Finished --------> Application Data <-------> Application Data
가장 큰 차이점은 ClientHello 메시지는 다시 시작하려는 세션 ID 에 대해 32 바이트를 추가로 포함한다는 것입니다.
기존 TLS 세션을 다시 시작하기 위한 총 오버 헤드는 평균적으로 약 330 바이트입니다 (15 + 16 + 202 + 75 + 2 * 1 + 2 * 12 = 332).
이제 암호화된 애플리케이션 데이터에 대한 전송의 오버 헤드를 살펴 보겠습니다. 데이터는 TLS 레코드에서 네트워크를 통해 전달되므로 5 바이트의 헤더가 있습니다. 데이터가 암호화되고 무결성 보호 되므로 추가 오버 헤드가 발생합니다. 클라이언트와 서버사이에서 협상 된 암호 슈트가 TLS_RSA_WITH_AES_128_CBC_SHA 라고 가정 해 봅시다. TLS1.2 에서는 필수 사항이며 일반적으로 앞으로 협상 될 것으로 기대됩니다. AES 는 블록 암호 이기 때문에 블록 크기의 배수로 데이터 크기를 조정해야합니다. TLS 1.0 은 블록 암호를 사용하여 암호화 된 데이터를 다음과 같이 정의합니다.
block-ciphered struct {
opaque content[TLSCompressed.length];
opaque MAC[CipherSpec.hash_size];
uint8 padding[GenericBlockCipher.padding_length];
uint8 padding_length;
} GenericBlockCipher;대부분의 구현은 압축을 사용하지 않으므로 데이터가 동일한 크기라고 가정 할 수 있습니다. 이 경우 MAC 은 SHA1 을 사용하여 계산되므로 크기는 20 바이트가 됩니다. AES128 의 블록 크기는 16 바이트 이므로 데이터에 추가 할 수 있는 최대 패딩은 15 바이트입니다.
암호화 된 데이터의 총 오버 헤드는 약 40 바이트 (20 + 15 + 5)입니다.
위의 계산을 수정하여 환경의 특성을 보다 정확하게 반영 할 수 있으므로 TLS 오버 헤드의 기초로 간주되어야 하기 때문에 질문에 대한 신뢰 할 수 있는 대답은 아니라는 점을 말씀 드립니다.