Chrome에서 "약한 임시 Diffie-Hellman 공개 키"를 무시하도록 설정

Chrome을 v45로 업데이트하면 약한 Diffie-Hellman 공개 키가있는 페이지에 대한 액세스가 차단됩니다. Logjam으로 인한 것임을 이해합니다. 경우에 따라 https에서 http로 전환하는 것이 "솔루션"이라는 것을 알고 있습니다.

그러나 인트라넷에서 사용하는 웹 기반 소프트웨어에 의해 https로 자동 리디렉션되므로 https에서 http로 전환 할 수 없습니다.

분명히 해결책은 다양한 인트라넷 서버가 logjam으로부터 안전하도록 보안을 변경하는 것입니다.하지만 지금 당장은 옵션이 아니며 수정 될 때까지 더 이상 작업을 수행 할 수 없습니다. 인트라넷이므로 단순히 연결하기 위해서는 물리적으로 여기 있어야하므로 위험은 미미합니다.

Chrome 버전 45의 약한 임시 Diffie-Hellman 공개 키를 사용하여 https 프로토콜을 통해 페이지에 계속 액세스 할 수있는 방법이 있습니까?

이 문제를 해결하기위한 해킹 수정 (Mac OSX)

• Chrome을 실행하는 동안 문제를 해결하려면 명령 줄에서 이것을 실행하십시오.

크롬:

open /Applications/Google\ Chrome.app --args --cipher-suite-blacklist=0x0088,0x0087,0x0039,0x0038,0x0044,0x0045,0x0066,0x0032,0x0033,0x0016,0x0013

카나리아:

open /Applications/Google\ Chrome\ Canary.app --args --cipher-suite-blacklist=0x0088,0x0087,0x0039,0x0038,0x0044,0x0045,0x0066,0x0032,0x0033,0x0016,0x0013

Firefox의 경우

• about : config로 이동
• 검색 security.ssl3.dhe_rsa_aes_128_sha및security.ssl3.dhe_rsa_aes_256_sha
• 둘 다로 설정하십시오 false.

참고 : 영구 수정은 길이가 1024보다 큰 DH 키를 업데이트하는 것입니다.

실제로 브라우저는 길이가 1024보다 낮은 키로 Diffie-Hellman 문제를 심각하게 받아들였으며, 이는 일부 좋은 소식이지만 다른 한편으로는 많은 Chrome 사용자를 생성했습니다 .

이 문제에 대한 수정 (및 보안과 관련된 다른 많은 것)은 시스템 관리자의 책임입니다. 이해하는 바와 같이, 약 512 비트 이하의 Diffie-Hellman 키를 제공하는 웹 사이트를 차단하기로 결정한 것은 원격 사이트에서 보안을 관리 하는 사용자는 영향을받는 사용자 의 "단점" 을 갖습니다.

현재 Chrome 브라우저를 --cipher-suite-blacklist= 0x0088,0x0087,0x0039,0x0038,0x0044,0x0045,0x0066,0x0032,0x0033,0x0016,0x0013LogJam 취약점과 관련된 기능을 비활성화하고 사용자가 사이트에 참여하도록 허용 하는 매개 변수 로 실행하여 Chrome 브라우저를 시작할 때 일부 Cipher Suites를 블랙리스트에 추가하는 것이 가능하지만 시스템 관리자의 책임이어야한다고 주장합니다. Diffie-Hellmann의 키로 문제를 해결합니다.

요청한 것 중 하나는 인트라넷 설정에서 나열된 해결 방법을 사용하거나 나열되지 않은 다른 방법을 사용하는 데 단점이 있는지 여부입니다. 짧은 대답은 관련된 서버가 약한 키를 사용하는 한 관련 서버는 로그 잼 공격을 사용하는 모든 시스템에 영향을 받기 쉬우 며 서버의 특성에 따라 서버가 서버를 전파 할 수있는 손상된 서버 일 수 있습니다 서버에 액세스하는 다른 클라이언트에게 문제가됩니다.

두 가지 시나리오는 인트라넷에 다시 연결할 때 내부 서버에 액세스하는 인트라넷에서 감염된 랩톱이거나 현재 인터넷에 액세스하는 데 사용되는 문제 (위와 다른 곳에서 제안 된)를 무시하도록 구성된 브라우저입니다. 인트라넷 서버를 공격하기 위해 손상된 서버에 연결하는 경우가 발생합니다.

Logjam 결함으로 인해 발생하는 모든 문제에 대해 개인적으로 잘 알고 있지 않기 때문에 두 가지 상황 중 하나가 특히 가능성이 있는지 말할 수 없습니다. 내 자신의 경험은 인터넷에 연결된 서버를 보유한 시스템 관리자가 가능한 한 이러한 문제보다 훨씬 앞서는 경향이 있다는 것입니다. 내 경험은 인트라넷 서버 관리자가 서버 보안 문제를 해결하기 전에 사이트를 예쁘게 만드는 것과 같은 일을하는 경향이 있다는 것입니다.

같은 문제에 직면했다. 서버 측 사람이라면 server.xml tomcat의 443 커넥터에 다음 줄을 추가하십시오.

sslProtocols = "TLSv1의, TLSv1.1, TLSv1.2"암호 = "TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256, TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA, TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384, TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA, TLS_ECDHE_RSA_WITH_RC4_128_SHA, TLS_RSA_WITH_AES_128_CBC_SHA256, TLS_RSA_WITH_AES_128_CBC_SHA, TLS_RSA_WITH_AES_256_CBC_SHA256, TLS_RSA_WITH_AES_256_CBC_SHA, SSL_RSA_WITH_RC4_128_SHA"

이렇게하면이 SSL 키 문제를 해결하는 데 도움이됩니다.