Defaults.Exposed › 수정 › 현대적 암호화 (TLS 버전 및 암호화 방식)

현대적 암호화 (TLS 버전 및 암호화 방식) 수정 방법

TLS는 방문자와 웹사이트 사이를 흐르는 데이터를 암호화하는 잠금 장치입니다. 이 잠금 장치를 신뢰할 수 있게 하는 두 가지가 있습니다: 현대적 TLS 버전 사용(오래되고 취약한 버전이 아님)과 강력한 암호화 방식 사용(실제 암호화 레시피). 이 페이지는 두 가지를 모두 다루며, 귀하의 등급에는 영향을 미치지 않지만 알아두면 좋은 몇 가지 관련 설정도 포함합니다.

비즈니스에 미치는 핵심 영향: 사이트가 오래된 암호화 또는 약한 암호화 방식을 사용하면 고객이 입력하는 개인 정보 — 로그인, 카드 번호, 연락처 — 가 공유 네트워크에서 조용히 가로채질 수 있으며, 은행, 결제 처리업체, 대형 고객사가 이제 거래 전에 요구하는 보안 검사에 실패할 수 있습니다.

발생 가능한 비용

고객이 호텔이나 카페 Wi-Fi에서 결제하거나 로그인합니다. 오래된 연결 또는 약한 암호화 방식으로 인해 같은 네트워크의 낯선 사람이 카드와 비밀번호를 실시간으로 읽습니다.
카드 결제를 신청하거나(또는 결제 제공업체가 재감사) 오래된 TLS나 금지된 암호화 방식이 결제 보안 규칙을 위반해 온라인 결제가 동결됩니다.
대형 고객사의 IT 팀이 서명 전 루틴 보안 스캔을 실행합니다. 사이트가 여전히 깨진 암호화를 허용하는 것을 발견하고 위험으로 표시합니다.
데이터 보호 불만이나 위반이 발생하면 규제 기관의 첫 번째 질문은 고객 데이터를 '적절하게' 보호했는지입니다. 수년 동안 공개적으로 알려진 취약한 암호화를 실행하는 것은 답변하기 매우 어렵습니다.
사이트에 자물쇠가 보여 모든 사람이 완전히 안전하다고 생각하고, 이 격차는 로그인 또는 카드 번호 하나가 사고로 이어질 때까지 수 년간 발견되지 않습니다.

중요한 이유. 안전한 암호화는 눈에 보이지 않습니다. 오래되거나 약한 암호화는 고객, 계약, 또는 규정 준수 통과를 잃는 날까지 조용히 앉아 있는 부채입니다. TLS 버전 및 암호화 방식 검사는 등급을 실제로 변동시키는 두 부분이며, 둘 다 일반적으로 하나의 무료 설정입니다.

쉬운 설명

누군가 웹사이트를 방문할 때 입력하는 모든 것 — 로그인, 카드 번호, 이름, 전화번호, 메시지 — 이 암호화되어 낯선 사람이 읽을 수 없습니다. 이 암호화를 수행하는 기술이 TLS(예전 이름인 SSL이라고도 합니다)입니다. 그 암호화가 실제로 안전하려면 두 가지가 맞아야 합니다:

TLS 버전 — 어떤 세대의 기술을 사용하는지. 초기 버전(TLS 1.0과 1.1)은 수년 동안 공개적으로 취약합니다. 안전한 것은 TLS 1.2와 TLS 1.3입니다.
암호화 방식 — TLS가 암호화를 수행하는 데 사용하는 구체적인 레시피. 일부(RC4, DES, 3DES)는 해독되어 금지되었습니다.

이 페이지는 두 가지를 모두 다룹니다. 사이트가 하나는 올바르고 다른 하나는 틀릴 수 있기 때문입니다. 두 가지 모두 일반적으로 같은 하나의 무료 변경으로 수정됩니다.

비즈니스 피해 사례

공공 Wi-Fi에서 고객이 피해를 입음. 누군가 호텔, 카페, 공항에서 로그인하거나 결제합니다. 오래된 TLS 버전이나 약한 암호화 방식이 허용되므로 같은 네트워크의 낯선 사람이 연결을 해독 가능한 옵션으로 강제 다운그레이드하고 비밀번호와 카드 번호를 실시간으로 읽습니다.
카드 결제가 꺼짐. 결제 보안 규칙(PCI DSS)은 최소 TLS 1.2와 RC4와 같은 약한 암호화 방식의 명시적 금지를 요구합니다.
보안 검토에서 거래가 지연됨. 더 큰 고객사가 서명 전 루틴 스캔을 실행합니다. 사이트가 여전히 깨진 암호화를 허용한다고 즉시 표시됩니다.
규제 기관이 어색한 질문을 함. 데이터 보호 기관의 첫 번째 질문은 개인 데이터를 “적절하게” 보호했는지입니다. 공개적으로 수년 동안 알려진 암호화를 사용하는 것은 방어하기 매우 어렵습니다.

실제 내용

TLS 버전

사이트는 하나의 TLS 버전만 지원하는 것이 아니라 여러 버전을 동시에 제공할 수 있습니다. 오래된 취약한 버전이 좋은 버전들 옆에 열린 뒷문으로 앉아 있을 수 있습니다: 공격자가 방문자의 연결을 TLS 1.0이나 1.1로 “다운그레이드”하도록 강제한 후 그 버전들의 알려진 약점을 악용할 수 있습니다.

점수 책정 방식:

TLS 1.3(1.2 있건 없건), 레거시 없음: 최선 결과. 만점.
TLS 1.2만, 1.3 없음: 안전하고 통과. 대부분의 점수.
TLS 1.0이나 1.1이 여전히 허용됨: 자동 실패, 제로 점수, 긴급으로 표시.

암호화 방식

버전이 선택되면 TLS는 암호화 방식 — 데이터를 암호화하는 실제 알고리즘 — 을 선택합니다. 금지되어 절대 사용해서는 안 되는 방식: RC4, DES, 3DES(Sweet32 공격에 취약), NULL(암호화 없음), EXPORT 등급 방식(FREAK 및 Logjam 공격), 익명 방식.

암호화 방식 검사는 두 가지를 합니다. 첫째로 서버가 실제로 협상한 방식을 봅니다. 그런 다음 — 중요한 부분 — 여러 알려진 취약한 방식을 적극적으로 시도합니다. 서버가 현대 클라이언트와 이야기할 때 강력한 방식을 선택할 수 있지만 공격자가 고집하면 약한 것을 수락할 수 있습니다.

세 가지 정보 제공 항목

세 가지 관련 항목이 보고되지만 등급에 영향을 미치지 않습니다:

TLS 압축(CRIME 공격): 현대 웹 서버에서 10년 이상 기본적으로 비활성화되어 있습니다.
OCSP 스테이플링: 성능 및 개인 정보 보호 개선. CDN이 자동으로 처리합니다.
안전한 재협상: TLS 1.3이 재협상을 완전히 제거했습니다.

수정 방법 (무료, 약 30분)

IT 담당자에게 이 섹션을 전달하세요 — 수정은 무료입니다.

가장 간단한 신뢰할 수 있는 접근 방식은 알려진 좋은 구성을 직접 작성하는 것보다 생성하는 것입니다: 서버 유형을 Mozilla SSL 구성 생성기 https://ssl-config.mozilla.org/에 붙여넣고 “중간” 프로파일(광범위한 호환성) 또는 “현대”(TLS 1.3만)를 선택합니다.

플랫폼별:

Cloudflare 또는 관리형 호스트 — 일반적으로 한두 번 클릭. Cloudflare에서: SSL/TLS → 엣지 인증서 → 최소 TLS 버전 → TLS 1.2.

Nginx. 최신 버전과 명시적 강력한 암호화 방식 목록 설정:

ssl_protocols TLSv1.2 TLSv1.3;
ssl_ciphers 'ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384';
ssl_prefer_server_ciphers on;

Apache. 오래된 버전 비활성화 및 강력한 암호화 방식 고정:

SSLProtocol all -SSLv3 -TLSv1 -TLSv1.1
SSLCipherSuite ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384
SSLHonorCipherOrder on

Windows / IIS. 무료 IIS Crypto 도구를 사용해 TLS 1.0과 1.1 비활성화, RC4/DES/3DES/NULL/EXPORT 방식 비활성화, TLS 1.2와 1.3 활성화.

흔한 실수

“자물쇠가 있으니 괜찮다.” 자물쇠는 보안 연결이 존재한다는 것만 증명합니다. 오래된 버전이나 금지된 방식이 배경에서 여전히 허용되는지는 알 수 없습니다.
버전은 수정했지만 암호화 방식은 아닌 경우(또는 반대). TLS 1.0/1.1을 비활성화해도 자동으로 RC4나 3DES가 제거되지 않습니다. 둘 다 설정하세요.
“레거시” 또는 “구 브라우저 호환성” 토글을 켜 둠. 많은 호스트와 CDN이 조용히 취약한 버전이나 약한 방식을 다시 활성화하는 옵션을 가지고 있습니다.
서버를 재로드/재시작하는 것을 잊음. 구성 변경은 웹 서버가 재로드될 때까지 적용되지 않습니다.
하나의 서버만 구성하고 나머지는 아닌 경우. 로드 밸런서, 여러 웹 서버, 또는 별도 하위 도메인을 운영한다면 각 TLS 엔드포인트가 동일한 구성이 필요합니다.

FAQ

기술적 지식이 없는데 직접 처리할 수 있나요?

기술적 세부 내용을 이해할 필요가 없습니다. 대부분의 현대 호스팅에서 이것은 한두 가지 설정이며 무료입니다. 아래 '수정 방법' 섹션을 웹사이트나 호스팅을 담당하는 사람에게 전달하세요.

현대적 암호화로 전환하면 일부 고객의 브라우저가 작동하지 않을 수 있나요?

실제로 그렇지 않습니다. 지난 약 10년간의 모든 현대 브라우저와 휴대폰은 기본적으로 이미 새로운 암호화와 강력한 방식을 사용합니다. 오래된 버전이나 약한 방식에 의존하는 것은 그 자체로 안전하지 않습니다.

사이트가 자물쇠와 함께 정상적으로 로드되는데 왜 여전히 표시되나요?

자물쇠는 보안 연결이 존재한다는 것만 의미합니다. 오래된 TLS 버전이나 금지된 암호화 방식이 좋은 것들 옆에 조용히 허용되는 상태에서도 완전히 정상적인 자물쇠를 보여줄 수 있습니다.

TLS 버전과 암호화 방식의 차이는 무엇인가요?

TLS 버전을 어떤 세대의 잠금 장치를 사용하는지로 생각하고, 암호화 방식을 데이터를 암호화하는 데 사용하는 구체적인 레시피로 생각하면 됩니다. 현대 잠금 장치(TLS 1.2 또는 1.3)를 가지면서도 오래되고 해독 가능한 레시피(RC4 또는 3DES)를 켜 둘 수 있습니다. 둘 다 맞아야 합니다.

OCSP 스테이플링과 TLS 압축은 등급에 영향을 미치나요?

아닙니다. 이것들(안전한 재협상 포함)은 정보 제공 목적으로만 보고됩니다. 성능과 심층 방어를 위해 중요하지만 점수를 변동시키지 않습니다.

수정이 정말 무료인가요?

그렇습니다. 오래된 TLS 버전 및 약한 암호화 방식을 비활성화하고 이러한 보호를 활성화하는 것은 기존 서버나 호스팅의 구성 변경입니다.