☰

OpenSSL(Cyrus imapd를 사용한 Outlook)의 ECDHE 키 교환 오류 - 해결 방법은 무엇입니까?

tag-icon • tag-icon openssl ssl cyrus-imapd
OpenSSL(Cyrus imapd를 사용한 Outlook)의 ECDHE 키 교환 오류 - 해결 방법은 무엇입니까?

포트 993에서 SSL 연결을 사용하고 키 협상에 ECDHE를 사용하여 Outlook 2019를 Cyrus imapd 서버에 연결하려고 합니다. 내가 무엇을 하든 imap 서버가 올바르게 설정되었음에도 불구하고 작동하지 않습니다.

이를 디버깅하기 위해 ssldump -a -A -H -i enp0s3서버에서 실행하고 연결을 시도하는 Outlook의 출력을 관찰했습니다(간결하게 하기 위해 첫 번째 C -> S 핸드셰이크에서 대부분의 암호 제품군 목록을 남겨 두었습니다).

New TCP connection #1: odo.lab.example.de(58717) <-> morn.lab.example.de(993)
1 1  0.0019 (0.0019)  C>S V3.3(178)  Handshake
      ClientHello
        Version 3.3
        random[32]=
          65 b1 2e 3c bb 7c 4d 04 03 0e 34 49 62 48 e5 d9
          22 c6 c9 c7 22 d4 e5 a0 76 44 64 9b a3 9d d5 bf
        cipher suites
        TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
        ...
        compression methods
                  NULL
        extensions
          server_name
              host_name: imap.lab.example.de
          supported_groups
          ec_point_formats
          signature_algorithms
          session_ticket
          extended_master_secret
          renegotiation_info
1 2  0.1245 (0.1225)  S>C V3.3(69)  Handshake
      ServerHello
        Version 3.3
        random[32]=
          3c ef 0c 80 c8 c2 35 85 90 20 8e 6f f4 e0 93 fe
          78 60 32 23 11 ec 56 df 3f f3 c6 e2 14 2f e5 2b
        session_id[0]=

        cipherSuite         TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
        compressionMethod                   NULL
        extensions
          renegotiation_info
          server_name
          ec_point_formats
          session_ticket
          extended_master_secret
1 3  0.1245 (0.0000)  S>C V3.3(1291)  Handshake
      Certificate
1 4  0.1245 (0.0000)  S>C V3.3(333)  Handshake
      ServerKeyExchange
        params
Not enough data. Found 327 bytes (expecting 32767)
1 5    0.1245   (0.0000)    S>C   V3.3(4)    Handshake
        ServerHelloDone
  1      0.1254   (0.0009)    C>S    TCP FIN
  1      0.1257   (0.0002)    S>C    TCP FIN

보시다시피 클라이언트와 서버는 필수 비밀번호( TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384)에 동의합니다. 다음으로, 서버는 클라이언트에 인증서를 보내는 것으로 나타납니다(자체 서명된 인증서이지만 Windows의 신뢰할 수 있는 루트 CA에 인증서를 추가했기 때문에 문제가 되지 않습니다).

그러나 키 교환에 문제가 있는 것 같습니다. Not enough data. Found 327 bytes (expecting 32767)거의 하루를 투자했음에도 불구하고 그것이 의미하는 바와 해결 방법을 평생 알 수 없습니다.

처음에는 이것이 인증서 파일에 누락된 DH 매개변수와 관련이 있을 수 있다고 생각했습니다. 그러나 (EC)DHE에는 이러한 매개변수가 필요하지 않습니다. 임시 버전의 목적은 매개변수를 동적으로 계산하고 주기적으로 교체하는 것이기 때문입니다.

IMAP 서버에서 사용하는 키나 인증서에 추가 정보를 추가해야 합니까? 새로 만들어야 한다면 문제가 되지 않습니다.

opensslCyrus imapd가 SSL/TLS 암호화를 위해 OpenSSL을 사용하기 때문에 이 질문에 태그를 할당했습니다 . 서버의 OpenSSL 버전은 1.1.1w입니다.

또한 Outlook(Windows 측)이 TLS 1.2를 사용하는지 확인했습니다. 이는 위에 표시된 콘솔 출력에 반영됩니다( Version 3.3TLS 1.2를 나타냄).

답변1

@Steffen Ullrich와 dave_thompson_085의 의견은 모두 정확합니다.

메시지는 Not enough data. Found 327 bytes (expecting 32767)서버나 클라이언트가 아닌 ssldump에서 나옵니다. 우리가 SSL 연결을 분석하는 데 사용하는 프로그램에 이와 같은 버그가 포함되어 있어 우리를 잘못된 경로로 설정한다는 것은 너무 안타까운 일입니다.

이 질문은 여러 가지 이유로 분석하기가 어렵습니다.

첫째, schannel 로깅은 일반적으로 Windows에서 활성화되지 않으며, 이를 켠 후에도 이벤트 뷰어에서 schannel에 대한 항목을 볼 수 없습니다. 그런데 몇 시간 뒤에 이런 메시지가 많이 떴습니다. (그동안 아무것도 바꾸지 않았다고 맹세합니다.)

둘째, "홈"이라는 다양한 소프트웨어 구성 요소(Windows 구성 요소 및 기타 응용 프로그램 및 서비스)에서 수많은 메시지가 있습니다. 약 1000개의 schannel 항목을 스크롤한 후 TLS 경고 43, 이벤트 ID 36888이 있는 항목 하나를 발견했습니다. 이 경고는 다음을 의미합니다 unsupported_certificate(참조여기30페이지).

셋째, 이 표현으로 인해 서버 인증서에 특수 키 사용 필드를 추가해야 한다고 생각하게 되었고(결국 확장이 됨) 이에 많은 시간을 낭비하게 되었습니다.

그러나 결국 Outlook(또는 schannel)은 서버 인증서가 만료되는 것을 좋아하지 않는다는 사실을 알게 되었습니다. 그러나 이것은 Thunderbird에서는 문제가 되지 않습니다. Windows는 실제로 문제가 무엇인지 파악할 수 없으며 대신 나에게 맞지 않는 쓸모없고 오해의 소지가 있는 오류 메시지를 표시합니다.

요약:

핵심 합의에는 문제가 없습니다. 대신, ssldump내가 사용한 버전에는 나를 오해하게 만드는 버그가 포함되어 있었습니다. 문제는 서버 인증서가 만료되었고 Outlook과 Windows가 합리적인 오류 메시지를 표시하지 않는다는 것입니다.

관련 정보