TLS 서버가 내가 이해할 수 없는 작업을 수행하고 있습니다.
- TCP 핸드셰이크가 정상적으로 실행됩니다.
- SSL 클라이언트 Hello가 정상적으로 실행됩니다.
- SSL Server Hello는 정상적인 것 같습니다. 인증서를 제공합니다. Server Hello Done이라고 표시됩니다.
- 해부에서는 클라이언트 문제 "클라이언트 키 교환, 암호 사양 변경, 암호화된 핸드셰이크 메시지"를 보여줍니다.
- 해부에서는 서버 문제 "암호화 사양 변경"과 "암호화된 핸드셰이크 메시지"를 보여줍니다.
이제 클라이언트가 ACK를 보내고 데이터 전송을 시작합니다. 그러나 서버 ACK는 "암호화된 경고"와 FIN을 보냅니다.
이는 인증서를 교체한 직후에 발생했습니다. SSL 핸드셰이크에 제시된 인증서가 새 키입니다.
단서, 누구?
답변1
클라이언트 또는 로드 밸런서와 같은 중간 장치의 SNI 문제 때문일 수 있습니다. 로드 밸런싱 장치는 초기 Client Hello의 일부로 서버 이름을 백엔드 호스트에 제공할 수 있어야 합니다. 보다https://en.m.wikipedia.org/wiki/Server_Name_Indication
답변2
가장 중요한 패킷은 연결이 닫히는 이유를 포함하는 "암호화된 경고"입니다.
유효성 검사 오류인 것 같습니다. 이는 인증서가 신뢰할 수 없거나 유효하지 않음을 의미합니다. 하지만 진짜 이유는TLS 경고 프로토콜
답변3
pure-ftpd명시적 TLS 모드(FTPS 서버)에서 비슷한 문제가 발생했습니다 .
내 경우에는 있었지만아니요 Encrypted Alert서버에서 전송됨; 키 교환 직후에 검색됩니다( Change Cipher Spec, Finished서버의 메시지 → 서버의 FIN). 다음,클라이언트Encrypted alert레벨 1 코드 0 Close Notify(서버 FIN과 달리 예상됨)을 보냈습니다 .
이는 하나의 특정 클라이언트(장치 펌웨어)에서만 발생했으며 다른 FTP 클라이언트에서는 재현되지 않았습니다.
문제의 근본 원인을 파헤치지는 않았지만 문제가 발생한 것 같습니다.서버 버그. pure-ftpd아파치와 같은 연결당 포크 모델을 사용합니다. 그리고 나는 관찰했다자식 프로세스 충돌gdb에서(코드 -1로 종료) — 물론 OS가 소켓 FD를 닫고 FIN을 전송하게 됩니다.
제 경우에는 서버 버그라고 말할 수 있는 또 하나의 이유가 있습니다. FTP 서버를 다른 구현으로 교체하자마자 동작이 재현되지 않았습니다 proftpd.
나는 이것이 OP 사례와 일치하지 않는다고 생각합니다. 서버는 암호화된 경고를 사용하여 TLS에 적합한 방식으로 연결을 종료합니다. 그럼에도 불구하고 이 페이지를 방문하는 모든 사람이 고려해야 할 사항입니다.