내 서버 버전(NGINX 1.16.0)과 OpenSSL 버전(1.0.2k)을Mozilla SSL 구성 생성기SSL 암호의 긴 목록을 얻었습니다.
예를 들어,
ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384;
그런데 제가 방문했을 때Cipherli.stNginx에는 두 개의 SSL 암호만 제공합니다.
ssl_ciphers EECDH+AESGCM:EDH+AESGCM;
사용 가능한 암호 수가 적으면 보안이 저하되거나 손상됩니까? 클라이언트에게 더 적은 수의 암호화 옵션을 제공하면 성능이 향상되거나 다른 중요한 특성이 조정됩니까?
답변1
TLS(및 그 이전 SSL)의 허용 사항 중 하나는 보안 연결이 시작될 때 서버와 클라이언트가 상호 지원하는 암호에 대해 협상하고 동의할 수 있다는 것입니다.
그 이유는 주로 호환성 때문입니다. 아직 새 암호를 지원하지 않는 클라이언트와 서버 간의 연결을 끊는 대신 새 암호를 점진적으로 도입할 수 있기 때문입니다.
협상 없이 단일 암호만 사용하면 이런 일이 발생합니다. 그런 다음 한 당사자가 이전 암호를 삭제하고 새 암호로 업그레이드하기로 결정하고 다른 당사자와 조정하지 않고 그렇게 하면 연결이 끊어집니다. 단일 조직에서는 서버와 클라이언트 모두의 동시 업그레이드를 조정하는 것이 이미 꽤 힘든 일이지만, 인터넷 전체에서는 이러한 대규모 업그레이드가 물론 거의 불가능합니다.
따라서 암호 협상이 좋습니다. (적어도 호환성을 위해서는)
사용 가능한 암호 수가 적으면 보안이 저하되거나 손상됩니까?
아니요.암호의 수보안을 결정하지 않습니다.
보안을 제공하는 것은 암호 자체입니다.
일부 암호는 다른 암호보다 상대적으로 더 안전하지만(다른 알고리즘 또는 더 긴 키 길이와 암호화 기능을 제공하는 동일한 알고리즘)전방보안일부는 다른 것보다 더 안전하게 만들 수 있으며 일부는 약하거나 심지어 손상되었습니다.보안 요구 사항을 충족하는 암호화 중 일부만 지원하고 전체 암호화를 지원하는 경우 추가적인 보안 이점은 없습니다.
(지원하는 각 암호는 소프트웨어 구현과 함께 제공되어야 한다는 약간의 주의 사항이 있습니다. 따라서 더 많은 암호 == 더 많은 코드 == 버그 및 구현 오류 가능성이 높아집니다...)
클라이언트에게 더 적은 수의 암호화 옵션을 제공하면 성능이 향상되거나 다른 중요한 특성이 조정됩니까?
아니요. 암호화마다 성능 통계와 사용 사례가 크게 다르지만, 암호화 수가 적을수록 코드 수가 적고 제로데이 익스플로잇에 대한 위험이 낮아진다는 위의 주의 사항을 제외하고는그만큼암호의 수서버 측 지원은 성능에 영향을 미치지 않습니다어떤 관련 방식으로든. 보안 요구 사항을 충족하는 암호화 중 일부만 지원하고 전체 암호화는 지원하지 않아도 추가적인 성능 이점은 없습니다.
지원되는 암호 수가 적다는 것은 호환성이 낮다는 것을 의미합니다.(일반적으로 서버를 이전 클라이언트가 지원하지 않거나 계산 비용이 너무 많이 드는 가장 강력한 최신 암호로 제한하기 때문입니다.)
사용자 에이전트 문자열을 기록하고 업데이트할 때 어떤 영향을 미칠지에 대한 목록을 작성합니다. 다음과 같은 테이블을 참조하여 웹 서버 보안 설정SSL Lab의 사용자 에이전트 기능 미리.