ERR_SSL_WEAK_EPHEMERAL_DH_KEY: 원인은 서버다

문제

ERR_SSL_WEAK_EPHEMERAL_DH_KEY는 브라우저 오류처럼 보이고, 실제로 그렇습니다 — 하지만 브라우저가 항의하는 대상은 완전히 반대편 끝에 있습니다. 브라우저가 TLS 핸드셰이크를 시작했고, 서버가 ephemeral Diffie-Hellman(DHE) 암호를 골랐는데, 서버가 제시한 Diffie-Hellman 그룹이 너무 작아 브라우저가 마무리를 거부한 것입니다. 브라우저는 예산만 있으면 나중에 복호할 수 있는 연결을 맺느니 오류 페이지를 보여주는 쪽을 택합니다.

그러니 먼저 새길 것은, 이건 당신 탓도 아니고 당신이 고칠 것도 아니라는 점입니다. 이걸 정직하게 사라지게 만드는 클라이언트 쪽 토글·캐시 삭제·설정은 없습니다. 이 오류는 브라우저가 하한선을 강제하는 것이고 — 그 하한선은 2015년 Logjam(CVE-2015-4000) 이후 인터넷이 합의한 것입니다. Logjam 연구진은 중간자가 TLS 세션을 export급 512비트 Diffie-Hellman으로 강제로 끌어내린 뒤 깰 수 있음을, 그리고 — 실제로 중요했던 부분 — 소수의 1024비트 소수가 흔한 서버 소프트웨어에 박혀 어디서나 재사용되기에, 소수 하나에 대한 사전계산으로 인터넷의 광범위한 부분을 한꺼번에 수동 복호할 수 있음을 보였습니다. 브라우저들은 1024비트 미만 DH 그룹을 거부하고, 이 검사를 건드리는 무엇이든 완전 차단으로 대응하며 응답했습니다.

증상

• 해당 시기의 Chrome/Chromium이 ERR_SSL_WEAK_EPHEMERAL_DH_KEY를 띄우고 페이지를 안 엽니다.
• Firefox는 “SSL received a weak ephemeral Diffie-Hellman key”(SSL_ERROR_WEAK_SERVER_EPHEMERAL_DH_KEY)를 보입니다.
• curl이나 openssl s_client가 dh key too small로 실패하고, Java는 “DH keypair too small” / 키 크기 오류를 던집니다.
• 나머지 웹은 정상인데 특정 사이트나 기기 하나 — 대개 오래된 것 — 만 그렇습니다. 최신 Chrome에선 대신 암호 불일치가 날 수 있는데, Chrome이 DHE를 통째로 버렸기 때문입니다.

주요 원인 3가지

1. 서버가 export급 또는 1024비트 미만 DHE를 제시 - 대놓고 고장 난 경우입니다. 레거시 TLS 설정이 아직 DHE_EXPORT나 512/768비트 Diffie-Hellman 그룹을 광고합니다 — 남은 export 암호, 옛 OpenSSL, 10년 전 설정을 복붙한 것. 모든 현행 클라이언트가 거부합니다. Logjam이 다룬 바로 그것이, 아직 돌아가는 겁니다.
2. 서버가 옛 기본 1024비트 공유 소수를 사용 - “기술적으론 하한선이지만 여전히 안 됨”인 경우입니다. 옛 Apache·nginx 빌드는 잘 알려진 1024비트 그룹을 기본으로 썼습니다. 브라우저는 마지못해 1024를 허용하지만, 엄격한 클라이언트·보안 스캐너·컴플라이언스 검사는 점점 이를 플래그합니다 — 공유 소수이고, 그게 정확히 Logjam이 악용한 약점이니까요. 정책이 한 번만 조여지면 깨집니다.
3. 아무도 업데이트 안 하는 레거시 장비 - 완고한 경우입니다. iDRAC/IPMI 컨트롤러, 네트워크 스위치, 프린터, 옛 메일 서버, 관리 콘솔은 작은 DH 파라미터로 출하돼 손대지 않습니다. Chrome으로는 만나지 못합니다 — Chrome은 DHE를 말하지 않으니까요 — curl, SDK, Java, 구형 브라우저로 만나 거기서 약한 키 오류를 받습니다.

DechoNet으로 진단

• SSL 점검은 서버가 TLS로 도달 가능한지 확인하고 인증서와 핸드셰이크 상태를 보여주므로, 명백한 첫 사실을 먼저 확립할 수 있습니다: 문제는 당신 기기가 아니라 서버의 TLS 설정이라는 것. 서버가 상수임을 알고 나면, 정확한 범인은 명령 하나 거리입니다.
• 정확한 Diffie-Hellman 크기는 OpenSSL로 얻으세요: openssl s_client -connect yourdomain.com:443 -cipher DHE를 실행하고 Server Temp Key 줄을 읽으면 DH 그룹 크기가 비트로 찍힙니다(예: DH, 1024 bits). 1024 이하는 무엇이든 클라이언트를 걸리게 하는 값입니다.

해결 체크리스트

• DH 크기를 확인하세요: openssl s_client -connect host:443 -cipher DHE 2>/dev/null | grep "Server Temp Key". DH, 512 bits나 DH, 1024 bits가 답입니다.
• 깔끔한 해법을 택하세요 — DHE를 버리고 ECDHE로. 서버를 타원곡선 ephemeral 키 교환 전용으로 설정하면(현대 암호 목록은 기본으로 이렇게 합니다) 공유 소수 문제가 통째로 사라집니다. 브라우저들이 다들 이쪽으로 밀어붙인 데는 이유가 있습니다.
• DHE를 꼭 유지해야 한다면(그게 필요한 클라이언트가 있다면) 강한 그룹을 생성하세요: openssl dhparam -out /etc/ssl/dhparams.pem 2048(최소 2048, 핸드셰이크 비용을 감당할 수 있으면 4096). 서버가 이를 가리키게 하세요 — nginx: ssl_dhparam /etc/ssl/dhparams.pem;, Apache 2.4.8+ & OpenSSL 1.0.2+: SSLOpenSSLConfCmd DHParameters "/etc/ssl/dhparams.pem".
• export·약한 암호를 명시적으로 끄세요(암호 문자열에 !EXPORT:!LOW:!aNULL). 다시 로드하고 openssl 점검을 재실행해 새 크기를 확인합니다.
• 재설정할 수 없는 장비라면, 앞에 현대적 리버스 프록시나 로드밸런서를 두고 거기서 TLS를 종단하세요 — 장비는 내부 구간에서 약한 암호를 말하고, 공개 엔드포인트는 ECDHE를 씁니다.

에스컬레이션 시점

• 당신 서버가 아니라면 — 벤더 포털, 파트너 API, 기기 내장 웹 UI — 해결은 그쪽 몫입니다. 운영자에게 Server Temp Key 출력을 보내세요. “당신 DH 그룹이 1024비트라 브라우저들이 거부하기 시작했다”는 막연한 불평이 아니라 구체적이고 실행 가능한 버그 리포트입니다.
• 기기를 정말로 업데이트할 수도, 프록시 뒤에 둘 수도 없다면, 약한 DH를 다시 켜는 브라우저 플래그에 손대지 마세요. 그건 아무것도 고치지 않습니다 — 이 사이트만이 아니라 모든 사이트에서, 공격자가 깰 수 있는 키를 받아들일 유일한 기계로 당신 클라이언트를 만들 뿐입니다.
• 현대적이라 여겼던 인프라에서 약한 DHE를 발견하면, 일회성이 아니라 설정 드리프트 발견으로 다루세요. 한 서비스에 숨은 1024비트 기본값은 대개 같은 템플릿이 다른 곳에도 배포됐다는 뜻입니다 — 스캐너나 더 엄격한 브라우저가 먼저 찾기 전에 나머지를 감사하세요.