ssl handshake pendurado na cadeia de certificados do CentOS 5.8 com o openssl 0.9.8e

2

Temos alguns servidores executando o CentOS 5.8 com o OpenSSL 0.9.8e

openssl version
OpenSSL 0.9.8e-fips-rhel5 01 Jul 2008

Ao tentar estabelecer a conexão com um LDAPS na porta 636 desses servidores (nossos servidores são clientes ssl aqui), a troca de SSL trava quando o servidor remoto está apresentando a cadeia de certificados:

openssl s_client -connect 192.168.127.18:636 -state -nbio
CONNECTED(00000003)
turning on non blocking io
SSL_connect:before/connect initialization
SSL_connect:SSLv2/v3 write client hello A
SSL_connect:error in SSLv2/v3 read server hello A
write R BLOCK
SSL_connect:error in SSLv3 read server hello A
SSL_connect:error in SSLv3 read server hello A
read R BLOCK
SSL_connect:error in SSLv3 read server hello A
read R BLOCK


openssl s_client -connect 192.168.127.18:636 -debug

[…]
1220 - 6c 75 74 69 6f 6e 73 2c-20 49 6e 63 2e 31 23 30   lutions, Inc.1#0
1230 - 21 06 03 55 04 03 13 1a-47 54 45 20 43 79 62 65   !..U....GTE Cybe
1240 - 72 54 72 75 73 74 20 47-6c 6f 62 61 6c 20 52 6f   rTrust Global Ro
1250 - 6f 74 00 63 30 61 31 0b-30 09 06 03 55 04 06 13   ot.c0a1.0...U...
1260 - 02 55 53 31 15 30 13 06-03 55 04 0a 13 0c 44 69   .US1.0...U....Di
1270 - 67 69 43 65 72 74 20 49-6e 63 31 19 30 17 06 03   giCert Inc1.0...
1280 - 55 04 0b 13 10 77 77 77-2e                        U....www.

Eu fiz uma captura de pacotes ao tentar estabelecer a conexão

packetcapture1.pcap

1   0.000000   10.12.0.70 → 192.168.127.18 TCP 74 58171→636 [SYN] Seq=0 Win=5840 Len=0 MSS=1460 SACK_PERM=1 TSval=3234347727 TSecr=0 WS=128
2   0.047751 192.168.127.18 → 10.12.0.70   TCP 74 636→58171 [SYN, ACK] Seq=0 Ack=1 Win=8192 Len=0 MSS=1200 WS=256 SACK_PERM=1 TSval=203188744 TSecr=3234347727
3   0.047766   10.12.0.70 → 192.168.127.18 TCP 66 58171→636 [ACK] Seq=1 Ack=1 Win=5888 Len=0 TSval=3234347775 TSecr=203188744
4   0.049056   10.12.0.70 → 192.168.127.18 SSLv2 187 Client Hello
5   0.095966 192.168.127.18 → 10.12.0.70   TCP 66 636→58171 [ACK] Seq=1 Ack=122 Win=66304 Len=0 TSval=203188744 TSecr=3234347776
6   0.097828 192.168.127.18 → 10.12.0.70   TCP 1254 [TCP segment of a reassembled PDU]
7   0.097838 192.168.127.18 → 10.12.0.70   TCP 1254 [TCP segment of a reassembled PDU]
8   0.097842 192.168.127.18 → 10.12.0.70   TCP 1254 [TCP segment of a reassembled PDU]
9   0.097845 192.168.127.18 → 10.12.0.70   TCP 1254 [TCP segment of a reassembled PDU]
10   0.097884   10.12.0.70 → 192.168.127.18 TCP 66 58171→636 [ACK] Seq=122 Ack=1189 Win=8320 Len=0 TSval=3234347825 TSecr=203188744
11   0.097893   10.12.0.70 → 192.168.127.18 TCP 66 58171→636 [ACK] Seq=122 Ack=2377 Win=10624 Len=0 TSval=3234347825 TSecr=203188744
12   0.097900   10.12.0.70 → 192.168.127.18 TCP 66 58171→636 [ACK] Seq=122 Ack=3565 Win=13056 Len=0 TSval=3234347825 TSecr=203188744
13   0.097905   10.12.0.70 → 192.168.127.18 TCP 66 58171→636 [ACK] Seq=122 Ack=4753 Win=15360 Len=0 TSval=3234347825 TSecr=203188744
14  11.904578   10.12.0.70 → 192.168.127.18 TCP 66 58171→636 [FIN, ACK] Seq=122 Ack=4753 Win=15360 Len=0 TSval=3234359632 TSecr=203188744
15  12.152238   10.12.0.70 → 192.168.127.18 TCP 66 [TCP Spurious Retransmission] 58171→636 [FIN, ACK] Seq=122 Ack=4753 Win=15360 Len=0 TSval=3234359879 TSecr=203188744
16  12.646227   10.12.0.70 → 192.168.127.18 TCP 66 [TCP Spurious Retransmission] 58171→636 [FIN, ACK] Seq=122 Ack=4753 Win=15360 Len=0 TSval=3234360373 TSecr=203188744
17  13.634171   10.12.0.70 → 192.168.127.18 TCP 66 [TCP Spurious Retransmission] 58171→636 [FIN, ACK] Seq=122 Ack=4753 Win=15360 Len=0 TSval=3234361361 TSecr=203188744

Quando especificamos ssl2 com openssl, a troca de ssl é negociada corretamente.

packetcapture2.pcap

openssl s_client  -connect 192.168.127.18:636 -ssl2

SSL-Session:
Protocol  : SSLv2
Cipher    : DES-CBC3-MD5
Session-ID: 67230000B3D8F8E135F4491CACBE5546
Session-ID-ctx:
Master-Key:
Key-Arg   : 6CA6AB4BCAA3A8B3
Krb5 Principal: None
Start Time: 1471624893
Timeout   : 300 (sec)
Verify return code: 21 (unable to verify the first certificate)

16   7.060533   10.12.0.70 → 192.168.127.18 TCP 74 36082→636 [SYN] Seq=0 Win=5840 Len=0 MSS=1460 SACK_PERM=1 TSval=3235617155 TSecr=0 WS=128
17   7.108438 192.168.127.18 → 10.12.0.70   TCP 74 636→36082 [SYN, ACK] Seq=0 Ack=1 Win=8192 Len=0 MSS=1200 WS=256 SACK_PERM=1 TSval=203315683 TSecr=3235617155
18   7.108456   10.12.0.70 → 192.168.127.18 TCP 66 36082→636 [ACK] Seq=1 Ack=1 Win=5888 Len=0 TSval=3235617203 TSecr=203315683
19   7.109678   10.12.0.70 → 192.168.127.18 SSLv2 111 Client Hello
20   7.156685 192.168.127.18 → 10.12.0.70   TCP 66 636→36082 [ACK] Seq=1 Ack=46 Win=66304 Len=0 TSval=203315683 TSecr=3235617204
21   7.157436 192.168.127.18 → 10.12.0.70   TCP 1254 [TCP segment of a reassembled PDU]
22   7.157492   10.12.0.70 → 192.168.127.18 TCP 66 36082→636 [ACK] Seq=46 Ack=1189 Win=8320 Len=0 TSval=3235617252 TSecr=203315683
23   7.157541 192.168.127.18 → 10.12.0.70   SSLv2 300 Server Hello
24   7.157592   10.12.0.70 → 192.168.127.18 TCP 66 36082→636 [ACK] Seq=46 Ack=1423 Win=10624 Len=0 TSval=3235617252 TSecr=203315688
25   7.158199   10.12.0.70 → 192.168.127.18 SSLv2 342 Client Master Key
26   7.211382 192.168.127.18 → 10.12.0.70   SSLv2 109 Encrypted Data
27   7.211440   10.12.0.70 → 192.168.127.18 SSLv2 109 Encrypted Data
28   7.259050 192.168.127.18 → 10.12.0.70   SSLv2 109 Encrypted Data
29   7.299348   10.12.0.70 → 192.168.127.18 TCP 66 36082→636 [ACK] Seq=365 Ack=1509 Win=10624 Len=0 TSval=3235617393 TSecr=203315698
30   9.400611   10.12.0.70 → 192.168.127.18 SSLv2 93 Encrypted Data
31   9.448256 192.168.127.18 → 10.12.0.70   TCP 60 636→36082 [RST, ACK] Seq=1509 Ack=392 Win=0 Len=0

1) Eu não entendo porque eu não vejo o Server Hello no pcap (mesmo comportamento ao habilitar o subdissector para remontar o TCP Stream) Parece também que o servidor está apresentando a cadeia de certificados antes do ServerHello (pacote # 21 em packetcapture2.pcap e # 6, # 7, # 8, # 9), eu não entendo esse comportamento também.

2) Nós não vemos este comportamento quando usamos o CentOS 6

Obrigado antecipadamente pela sua ajuda,

    
por Virtuose 19.08.2016 / 18:37

1 resposta

0

O problema estava no SSLCipherSuite, para resolver o bug do poodle, como sugerido, tive que desabilitar o protocolo SSL e modificar o SSLCipherSuite. O SSLCipherSuite usado perdeu o código do Windows Mobile e Explorer 11, então eu resolvi usar um SSLCipherSuite atualizado.

No artigo vinculado, o mozilla sugere 3 SSLCipherSuite diferentes com base na compatibilidade legada dos navegadores.

Servidor Vietnã | Server Vietnam

    
por 25.08.2016 / 06:23