☰

Apache에서 SSLCompression을 끌 수 없습니까?

tag-icon • tag-icon ssl apache-2.4 compression gzip
Apache에서 SSLCompression을 끌 수 없습니까?

내 Apache는 2.4.46이고 Openssl 버전 1.1.1f를 사용하고 있습니다.

지시문을 설정했습니다 SSLCompression Off. 활성화해도 SSL 압축이 지원되지 않는다고 나오네요. 좋은 것 같아요.

하지만 Firefox를 사용하여 웹페이지의 HTTP 헤더를 보면 다음과 같은 응답 헤더가 표시됩니다.

HTTP/2 200 OK
date: Fri, 25 Dec 2020 12:13:58 GMT
server: Apache
expires: -1
cache-control: no-store, no-cache, must-revalidate, max-age=0
pragma: no-cache
content-security-policy: default-src https: 'unsafe-inline' 'unsafe-hashes' 'self'; img-src data: https: 'self'
x-frame-options: DENY
x-xss-protection: 1; mode=block
x-content-type-options: nosniff
strict-transport-security: max-age=63072000; includeSubDomains; preload
referrer-policy: no-referrer
permissions-policy: geolocation=();midi=();notifications=();push=();sync-xhr=(self);microphone=();camera=();magnetometer=();gyroscope=();speaker=(self);vibrate=();fullscreen=(self);payment=();
vary: Accept-Encoding
content-encoding: gzip
content-length: 3299
content-type: text/html; charset=UTF-8
X-Firefox-Spdy: h2

말하는 것 : content-encoding: gzip걱정됩니다.

그러나 cURL을 사용하여 PHP에서 이 스크립트를 사용하여 페이지를 가져오더라도:

curl_setopt($ch, CURLOPT_RETURNTRANSFER, 1);
//enable headers
curl_setopt($ch, CURLOPT_HEADER, 1);
//get only headers
curl_setopt($ch, CURLOPT_NOBODY, 1);
curl_setopt($ch, CURLOPT_TIMEOUT_MS, 5000);
curl_setopt($ch, CURLOPT_SSL_VERIFYPEER, 0);
curl_setopt($ch, CURLOPT_SSL_VERIFYHOST, false);
curl_setopt($ch, CURLOPT_HTTP_VERSION, CURL_HTTP_VERSION_2_0);
curl_setopt($ch, CURLOPT_USERAGENT, "Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:84.0) Gecko/20100101 Firefox/84.0");
curl_setopt($ch, CURLOPT_ENCODING, "gzip");

다음 HTTP 헤더를 반환합니다.


HTTP/2 200 
date: Fri, 25 Dec 2020 12:16:45 GMT
server: Apache
set-cookie: __Secure-CCJRLSESSID=g7m99kljvea2g5uk58f5lfskr1; path=/; secure; HttpOnly; SameSite=Lax
expires: -1
cache-control: no-store, no-cache, must-revalidate, max-age=0
pragma: no-cache
content-security-policy: default-src https: 'unsafe-inline' 'unsafe-hashes' 'self'; img-src data: https: 'self'
x-frame-options: DENY
x-xss-protection: 1; mode=block
x-content-type-options: nosniff
strict-transport-security: max-age=63072000; includeSubDomains; preload
referrer-policy: no-referrer
permissions-policy: geolocation=();midi=();notifications=();push=();sync-xhr=(self);microphone=();camera=();magnetometer=();gyroscope=();speaker=(self);vibrate=();fullscreen=(self);payment=();
content-type: text/html; charset=UTF-8

나를 혼란스럽게합니다. Firefox에서 캐시도 삭제했지만 운이 없었습니다. 나는 CRIME 공격에 취약해지고 싶지 않습니다. 그러면 gzip을 완전히 비활성화할 수 있습니다. 하지만 그 전에 왜 이런 일이 발생하는지 알고 싶습니다. 아마도 Firefox의 버그일까요??

업데이트:

크롬에서도 발생합니다.

mod_deflate conf:

SSLCompression Off
<IfModule deflate_module>
  AddOutputFilterByType DEFLATE application/javascript
  AddOutputFilterByType DEFLATE application/rss+xml
  AddOutputFilterByType DEFLATE application/vnd.ms-fontobject
  AddOutputFilterByType DEFLATE application/x-font
  AddOutputFilterByType DEFLATE application/x-font-opentype
  AddOutputFilterByType DEFLATE application/x-font-otf
  AddOutputFilterByType DEFLATE application/x-font-truetype
  AddOutputFilterByType DEFLATE application/x-font-ttf
  AddOutputFilterByType DEFLATE application/x-javascript
  AddOutputFilterByType DEFLATE application/xhtml+xml
  AddOutputFilterByType DEFLATE application/xml
  AddOutputFilterByType DEFLATE font/opentype
  AddOutputFilterByType DEFLATE font/otf
  AddOutputFilterByType DEFLATE font/ttf
  AddOutputFilterByType DEFLATE image/svg+xml
  AddOutputFilterByType DEFLATE image/x-icon
  AddOutputFilterByType DEFLATE text/css
  AddOutputFilterByType DEFLATE text/html
  AddOutputFilterByType DEFLATE text/javascript
  AddOutputFilterByType DEFLATE text/plain
  AddOutputFilterByType DEFLATE text/xml
</IfModule>

답변1

귀하의 질문에 대답하려면 배경에 대해 조금 아는 것이 도움이 됩니다.

배경 - 압축을 사용하는 것이 잠재적으로 보안 위험을 초래할 수 있는 이유는 무엇입니까?

기본적으로 압축 결과를 사용하여 원본 텍스트를 추측하는 소위 "압축 부채널 공격"이 몇 가지 있습니다. 각각은 기본적으로 입력을 압축에 추가한 다음 출력을 관찰하는 방식으로 작동합니다. 이는 많은 압축 알고리즘이 텍스트 전체를 여러 번 반복하는 대신 반복되는 텍스트를 인식하고 이를 참조로 바꾸는 방식으로 작동하기 때문입니다. 이로 인해 메시지 크기는 작아지지만 공격 기회가 생깁니다.

이러한 공격은 어떻게 작동하나요?

기본적으로 비밀 부분의 일부 또는 전부를 추측하고 이를 알 수 없는 비밀 부분과 함께 메시지에 추가한 다음 암호화된 결과의 크기를 관찰하고 특정 추측으로 작아지면 해당 부분을 반복한 것임에 틀림없습니다. 메시지는 더 높은 압축률로 인해 이점을 얻었습니다.

몇 가지 추측을 통해 비밀 부분을 알아내는 것이 가능합니다. 이를 수행하는 방법은 메시지에 추가할 수 있는지 여부에 따라 다르지만 이를 수행하는 방법은 다양합니다. 예를 들어 example.com에 대한 쿠키 세트를 알고 싶다면 token메시지(사람들이 전혀 관련이 없는 사이트를 방문할 때 발생하는 숨겨진 XHR 메시지일까요?)를 보내고 example.com?token=1결과 메시지 크기를 측정합니다(브라우저가 자동으로 추가하므로). 메시지에도 쿠키가 포함됩니다). 그런 다음 example.com?token=2크기가 더 큰지, 작은지, 같은지 확인해보세요. 메시지가 더 작아지는 쿠키의 첫 번째 문자를 찾을 때까지 가능한 모든 값에 대해 이 작업을 반복합니다. 이 예에서는 이라고 가정해 보겠습니다 token=5. 그런 다음 두 번째 문자(예 example.com?token=51: , example.com?token=52... 등)를 사용해 보십시오. 전체 쿠키를 얻을 때까지 반복하십시오.

메시지의 길이를 직접 측정할 수 있습니다(예: 가능한 경우 암호화된 메시지를 관찰하여).중간에있는 남성네트워크) 또는 메시지를 보내는 데 걸리는 시간을 측정하여 길이를 추측할 수 있습니다.

HTTP 메시지는 여러 가지 방법으로 압축될 수 있습니다.

압축은 HTTP 메시지의 다양한 수준(1) SSL/TLS 수준, 2) HTTP 본문 수준, 3) HTTP 헤더 수준에서 발생할 수 있습니다.

SSL 압축

SSL/TLS 압축 수행은 기본적으로 아래에 HTTP 메시지가 있다는 사실에 관계없이 발생하며 SSL/TLS 수준에서 수행됩니다. 다음과 같은 공격범죄SSL/TLS 압축은 기본적으로 위의 알고리즘을 사용하여 메시지의 숨겨진 부분을 추측할 수 있는 방법이 너무 많기 때문에 기본적으로 우리가 SSL/TLS 압축을 사용할 수 없게 되었습니다. 솔직히 말해서 SSL/TLS 압축의 이점은 그다지 크지 않았습니다. 특히 gzip 등을 사용하여 기본 HTTP 수준에서 본문 응답을 이미 압축한 경우에는 암호화 후 다시 압축해도 그다지 절약되지 않았습니다. 더 많은 데이터. 그래서 그것을 사용할 실제 이유가 없으며 이것이 실제 이유를 제공했습니다.아니다그것을 사용하기 위해. SSL/TLS 압축은 항상 꺼야 하며 다음과 같은 도구를 사용해야 합니다.SSLLabs이것을 확인하기 위해. 대부분의 서버에서는 기본적으로 꺼져 있으며 한동안 켜져 있었으므로 켜져 있으면 매우 놀랄 것입니다.

HTTP 본문 압축

HTTP 본문 수준의 압축이 더 흥미롭습니다. 이는 일반적으로 gzip 또는 최신 Brotli 알고리즘을 사용하며이다웹 성능이 크게 향상되므로 대부분의 경우 켜는 것이 좋습니다. 이는 HTTP 본문이 대개 크고(특정 응답 본문) 네트워크가 일반적으로 상대적으로 느리기 때문입니다. 따라서 네트워크 전체에 더 작은 크기를 전송하면 실질적인 이점이 있습니다. 이론상으로 이것은 유사한 공격에 취약합니다(소위위반 공격그리고 또한시간변형) — 그러나 비밀 데이터가 다시 본문에 있는 경우에만 해당됩니다(따라서 동일한 추측은 압축 후 더 작아질 수 있습니다). 따라서 대부분의 응답에는 비밀 데이터(예: 쿠키가 페이지 화면에 인쇄된 것을 마지막으로 본 것이 언제입니까?)가 포함되어 있지 않기 때문에 위험이 훨씬 적습니다. 반면 헤더의 쿠키는 항상 포함되고 메시지의 더 큰 부분을 차지합니다. .

물론 화면에 인쇄되는 비밀 정보(이름, 주민등록번호, DoB, 은행 정보 등)가 있는 경우 취약할 수 있으므로 해당 응답을 HTTP로 압축하지 않는 것을 고려해야 할 수도 있지만 매우 비정형적입니다. 따라서 HTTP 압축을 비활성화하면모든응답이 정답인 경우는 거의 없습니다. 화면에 비밀 정보를 표시하는 경우에도 더 나은 옵션이 있습니다. 예를 들어 해당 데이터를 화면에 전혀 표시하지 않거나 최소한 전체(예: 마지막 4자리를 제외하고 모두 별표 표시), 사용자 응답 데이터 표시를 허용하지 않음 예를 들어 동시에 화면에서 데이터를 임의의 문자로 채우거나 속도 제한을 추가하는 것이 일반적으로 훨씬 더 나은 옵션입니다.

질문으로 돌아가기

따라서 귀하의 질문에 대답하자면 SSL 압축과 HTTP 본문 압축은 서로 다른 두 가지이며 전자는 다음과 같습니다.끄다그리고 후자~에(이득에도 불구하고 위험을 감수하고 싶지 않은 정말 안전한 애플리케이션은 제외합니다. 하지만 그렇더라도 일반적으로 이를 처리할 수 있는 더 나은 방법이 있습니다.)

마무리하기 위해 HTTP 헤더 압축에 대한 몇 가지 보너스 정보를 제공합니다.

이야기를 마무리하기 위해 HTTP 헤더 압축에 대해 이야기하겠습니다. 왜냐하면 위와 같이 HTTP 헤더 압축에는 공격자가 가치 있다고 생각할 쿠키 비밀이 포함되는 경우가 많기 때문입니다.

아주 최근까지 널리 사용되는 버전이었던 HTTP/1.1은 이를 허용하지 않았기 때문에 여기서는 별로 이야기할 것이 없었습니다. 이는 압축되지 않은 전체 형식(HTTPS가 사용되는 경우 SSL/TLS를 사용하여 암호화됨)으로 전송되므로 사이드 채널 압축 위험에 취약하지 않습니다(SSL 압축이 사용되지 않는다고 가정).

이는 일반적으로 HTTP 본문에 비해 매우 작기 때문에 아무도 너무 많이 압축하는 것에 대해 걱정하지 않았습니다. 그러나 웹 페이지를 구성하는 데 사용되는 리소스 수가 증가함에 따라(요즘에는 100개가 넘는 것이 드문 일이 아님) 거의 동일한 HTTP 헤더를 항상 앞뒤로 보내는 데 많은 중복이 발생합니다. 예를 들어 모든 단일 요청과 함께 전송되지만 모든 요청에 ​​대해 변경되지 않는 사용자 에이전트 헤더의 예입니다.

따라서 최신 HTTP/2와 곧 출시될 HTTP/3 프로토콜은 HTTP 헤더 압축을 허용하지만 특히 이러한 공격에 취약하지 않은 압축 알고리즘(HTTP/2용 HPACK 및 HTTP/3용 유사한 QPACK)을 선택합니다. HTTP/2의 기반이 된 이전 SPDY 프로토콜은 gzip을 사용하여 취약했기 때문에 이것은 명시적인 선택이었습니다. 따라서 이것이 플래그 지정되면 이를 HTTP/2로 표준화하는 과정의 일부로 변경해야 했습니다.

왜 항상 "안전한 압축"을 사용하지 않습니까?

그렇다면 HTTP 응답 본문에도 안전한 압축 기술(예: HPACK 또는 QPACK)을 사용하여 이를 방지할 수 없는 이유는 무엇일까요? 음, 이는 사전이나 알려지고 반복되는 값을 사용하는 매우 구체적인 압축 기술입니다. 이는 값이 거의 없고 많이 반복되는 HTTP 헤더에 적합하지만 실제로 각 응답이 완전히 다를 수 있는 보다 일반적인 목적의 HTTP 본문 응답에 대한 옵션은 아닙니다.

이것이 몇 가지 사항을 설명하고 귀하의 질문에 답변이 되기를 바랍니다.

답변2

범죄 공격CVE-2012-4929암호화되지 않은 데이터의 길이를 적절하게 난독화하지 않고 압축된 헤더를 암호화하여 (추측을 통해) 일반 텍스트 헤더를 공개할 수 있게 하는 것입니다.

귀하의 상황에서는 내용이 압축되고, 압축된 데이터의 크기(길이)가 또 다른 헤더로 추가된 후 이 모든 것이 암호화됩니다. 암호화되지 않은 데이터의 길이는 절대 공개되지 않으므로 CRIME 공격에 취약하지 않습니다.

관련 정보