하위 도메인(회색)과 종속성(흰색)이 있는 HTTPS로 보호되는 Alexa의 상위 사이트(가운데 원) 중 하나이며 그 중 취약한 사이트(점선 음영)가 있습니다.

오늘날 HTTPS 보안 연결 아이콘은 모든 진지한 사이트의 표준이자 필수 속성이 되었습니다. 만약에 증명서 누락되면 거의 모든 최신 브라우저에 다음과 같은 경고가 표시됩니다. 사이트 연결이 "안전하지 않음" 기밀 정보를 전송하지 않는 것이 좋습니다.

그러나 주소 표시줄에 "잠금"이 있다고 해서 항상 보호가 보장되는 것은 아닙니다. 10개의 주요 사이트 확인 평가에서 Alexa는 그들 중 다수가 일반적으로 하위 도메인 또는 종속성을 통해 SSL/TLS 프로토콜의 심각한 취약점에 노출되어 있음을 보여주었습니다. 연구 저자에 따르면 최신 웹 애플리케이션의 복잡성으로 인해 공격 표면이 크게 증가합니다.

연구 결과

이 연구는 University of Venice Ca' Foscari(이탈리아)와 Vienna Technical University의 전문가들이 수행했습니다. 그들은 40년 20월 22일부터 2019일까지 샌프란시스코에서 열리는 제XNUMX회 IEEE 보안 및 프라이버시 심포지엄에서 자세한 보고서를 발표할 예정입니다.

상위 10개의 Alexa 목록 HTTPS 사이트와 000개의 관련 호스트가 테스트되었습니다. 취약한 암호화 구성이 90개 호스트, 즉 총 호스트의 약 816%에서 탐지되었습니다.

• 4818 MITM에 취약
• 733은 전체 TLS 복호화에 취약합니다.
• 912는 부분 TLS 복호화에 취약합니다.

898개 사이트는 해킹에 완전히 노출되어 있습니다. 즉, 외부 스크립트 삽입을 허용하고 977개 사이트는 공격자가 상호 작용할 수 있는 제대로 보호되지 않은 페이지에서 콘텐츠를 로드합니다.

연구원들은 898개의 "완전히 손상된" 리소스 중 온라인 상점, 금융 서비스 및 기타 대규모 사이트가 있다고 강조합니다. 660개 사이트 중 898개 사이트가 취약한 호스트에서 외부 스크립트를 다운로드합니다. 이것이 위험의 주요 원인입니다. 저자에 따르면 최신 웹 애플리케이션의 복잡성은 공격 표면을 크게 증가시킵니다.

다른 문제도 발견되었습니다. 승인 양식의 10%는 정보의 보안 전송에 문제가 있어 암호 유출 위협이 있으며, 412개 사이트는 쿠키 가로채기와 세션 하이재킹을 허용하고, 543개 사이트는 쿠키 무결성에 대한 공격(하위 도메인을 통해)을 받습니다. .

문제는 최근 SSL/TLS 프로토콜과 소프트웨어에서 여러 취약점을 확인했습니다: POODLE(CVE-2014-3566), BEAST(CVE-2011-3389), CRIME(CVE-2012-4929), BREACH(CVE-2013-3587) 및 Heartbleed(CVE-2014-0160). 이를 방지하려면 이전의 취약한 버전을 사용하지 않도록 서버와 클라이언트 측에 여러 가지 설정이 필요합니다. 그러나 이러한 설정에는 이해하기 매우 어려운 광범위한 암호 및 프로토콜 세트 중에서 선택하는 것이 포함되기 때문에 이것은 다소 간단한 절차가 아닙니다. 어떤 암호화 제품군과 프로토콜이 "충분히 안전한" 것으로 간주되는지가 항상 명확한 것은 아닙니다.

권장 설정

권장되는 HTTPS 설정 목록에 공식적으로 승인되고 동의된 사람은 없습니다. 그래서, Mozilla SSL 구성 생성기 필요한 보호 수준에 따라 여러 구성 옵션을 제공합니다. 예를 들어 nginx 1.14.0 서버에 대한 권장 설정은 다음과 같습니다.

모던 모드

가장 오래된 지원 클라이언트: Firefox 27, Chrome 30, IE 11에서 Windows 7, 엣지, 오페라 17, 사파리 9, Android 5.0 및 Java 8

server {
listen 80 default_server;
listen [::]:80 default_server;

# Redirect all HTTP requests to HTTPS with a 301 Moved Permanently response.
return 301 https://$host$request_uri;
}

server {
listen 443 ssl http2;
listen [::]:443 ssl http2;

# certs sent to the client in SERVER HELLO are concatenated in ssl_certificate
ssl_certificate /path/to/signed_cert_plus_intermediates;
ssl_certificate_key /path/to/private_key;
ssl_session_timeout 1d;
ssl_session_cache shared:SSL:50m;
ssl_session_tickets off;


# modern configuration. tweak to your needs.
ssl_protocols TLSv1.2;
ssl_ciphers 'ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256';
ssl_prefer_server_ciphers on;

# HSTS (ngx_http_headers_module is required) (15768000 seconds = 6 months)
add_header Strict-Transport-Security max-age=15768000;

# OCSP Stapling ---
# fetch OCSP records from URL in ssl_certificate and cache them
ssl_stapling on;
ssl_stapling_verify on;

## verify chain of trust of OCSP response using Root CA and Intermediate certs
ssl_trusted_certificate /path/to/root_CA_cert_plus_intermediates;

resolver <IP DNS resolver>;

....
}

중간 지원

가장 오래된 지원 클라이언트: 파이어폭스 1, 크롬 1, IE 7, 오페라 5, 사파리 1 Windows XP IE8, Android 2.3, 자바 7

server {
listen 80 default_server;
listen [::]:80 default_server;

# Redirect all HTTP requests to HTTPS with a 301 Moved Permanently response.
return 301 https://$host$request_uri;
}

server {
listen 443 ssl http2;
listen [::]:443 ssl http2;

# certs sent to the client in SERVER HELLO are concatenated in ssl_certificate
ssl_certificate /path/to/signed_cert_plus_intermediates;
ssl_certificate_key /path/to/private_key;
ssl_session_timeout 1d;
ssl_session_cache shared:SSL:50m;
ssl_session_tickets off;

# Diffie-Hellman parameter for DHE ciphersuites, recommended 2048 bits
ssl_dhparam /path/to/dhparam.pem;

# intermediate configuration. tweak to your needs.
ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
ssl_ciphers 'ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA:ECDHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA256:DHE-RSA-AES256-SHA:ECDHE-ECDSA-DES-CBC3-SHA:ECDHE-RSA-DES-CBC3-SHA:EDH-RSA-DES-CBC3-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:DES-CBC3-SHA:!DSS';
ssl_prefer_server_ciphers on;

# HSTS (ngx_http_headers_module is required) (15768000 seconds = 6 months)
add_header Strict-Transport-Security max-age=15768000;

# OCSP Stapling ---
# fetch OCSP records from URL in ssl_certificate and cache them
ssl_stapling on;
ssl_stapling_verify on;

## verify chain of trust of OCSP response using Root CA and Intermediate certs
ssl_trusted_certificate /path/to/root_CA_cert_plus_intermediates;

resolver <IP DNS resolver>;

....
}

이전 지원

가장 오래된 지원 클라이언트: Windows XP IE6, 자바 6

server {
listen 80 default_server;
listen [::]:80 default_server;

# Redirect all HTTP requests to HTTPS with a 301 Moved Permanently response.
return 301 https://$host$request_uri;
}

server {
listen 443 ssl http2;
listen [::]:443 ssl http2;

# certs sent to the client in SERVER HELLO are concatenated in ssl_certificate
ssl_certificate /path/to/signed_cert_plus_intermediates;
ssl_certificate_key /path/to/private_key;
ssl_session_timeout 1d;
ssl_session_cache shared:SSL:50m;
ssl_session_tickets off;

# Diffie-Hellman parameter for DHE ciphersuites, recommended 2048 bits
ssl_dhparam /path/to/dhparam.pem;

# old configuration. tweak to your needs.
ssl_protocols SSLv3 TLSv1 TLSv1.1 TLSv1.2;
ssl_ciphers 'ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:ECDHE-RSA-DES-CBC3-SHA:ECDHE-ECDSA-DES-CBC3-SHA:EDH-RSA-DES-CBC3-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:AES:DES-CBC3-SHA:HIGH:SEED:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!PSK:!RSAPSK:!aDH:!aECDH:!EDH-DSS-DES-CBC3-SHA:!KRB5-DES-CBC3-SHA:!SRP';
ssl_prefer_server_ciphers on;

# HSTS (ngx_http_headers_module is required) (15768000 seconds = 6 months)
add_header Strict-Transport-Security max-age=15768000;

# OCSP Stapling ---
# fetch OCSP records from URL in ssl_certificate and cache them
ssl_stapling on;
ssl_stapling_verify on;

## verify chain of trust of OCSP response using Root CA and Intermediate certs
ssl_trusted_certificate /path/to/root_CA_cert_plus_intermediates;

resolver <IP DNS resolver>;

....
}

항상 전체 암호 제품군과 최신 버전의 OpenSSL을 사용하는 것이 좋습니다. 서버 설정의 암호 제품군은 클라이언트 설정에 따라 사용될 우선 순위를 지정합니다.

연구에 따르면 HTTPS 인증서를 설치하는 것만으로는 충분하지 않습니다. "우리는 2005년처럼 쿠키를 처리하지 않고 '괜찮은 TLS'가 일반화되었지만 이러한 기본 사항으로는 매우 인기 있는 사이트를 놀라울 정도로 많이 확보하기에는 충분하지 않은 것으로 나타났습니다." говорят 작품의 저자. 서버와 클라이언트 간의 채널을 안정적으로 보호하려면 사이트의 콘텐츠가 제공되는 자체 하위 도메인 및 타사 호스트에서 인프라를 주의 깊게 모니터링해야 합니다. 정보 보안을 전문으로 하는 제XNUMX자 회사에 감사를 의뢰하는 것이 이치에 맞을 수도 있습니다.

출처 : habr.com