On Thu 2013-10-17 11:30:09 -0400, João Távora <[email protected]> wrote: > I'm on Microsoft Windows XP. Using gnutls 3.1.8-w32, I get in some > servers, but not others: > > $ ./gnutls-cli -p 443 siscog.campfirenow.com
trying with this server using gnutls 3.2.4 on debian: 0 dkg@alice:~$ gnutls-cli --debug 9999 siscog.campfirenow.com [...] |<3>| HSK[0xf5fec0]: SERVER HELLO (2) was received. Length 95[95], frag offset 0, frag length: 95, sequence: 0 |<3>| HSK[0xf5fec0]: Server's version: 3.3 |<3>| HSK[0xf5fec0]: SessionID length: 32 |<3>| HSK[0xf5fec0]: SessionID: 8380f0fd7f664bef694585d3a5ecab256a5b10adf2fa3206c684832c88d20371 |<3>| HSK[0xf5fec0]: Selected cipher suite: ECDHE_RSA_AES_128_CBC_SHA1 |<3>| HSK[0xf5fec0]: Selected compression method: NULL (0) |<3>| EXT[0xf5fec0]: Parsing extension 'SAFE RENEGOTIATION/65281' (1 bytes) |<3>| EXT[0xf5fec0]: Parsing extension 'SERVER NAME/0' (0 bytes) |<3>| EXT[0xf5fec0]: Parsing extension 'SUPPORTED ECC/10' (4 bytes) |<2>| ASSERT: ecc.c:95 |<2>| ASSERT: gnutls_extensions.c:207 |<2>| ASSERT: gnutls_handshake.c:1801 |<2>| ASSERT: gnutls_handshake.c:2225 |<2>| ASSERT: gnutls_handshake.c:1442 |<2>| ASSERT: gnutls_handshake.c:2701 *** Fatal error: An illegal TLS extension was received. |<4>| REC: Sending Alert[2|110] - An unsupported extension was sent |<4>| REC[0xf5fec0]: Preparing Packet Alert(21) with length: 2 and target length: 2 |<9>| ENC[0xf5fec0]: cipher: NULL, MAC: MAC-NULL, Epoch: 0 |<7>| WRITE: enqueued 7 bytes for 0x4. Total 7 bytes. |<7>| WRITE FLUSH: 7 bytes in buffer. |<7>| WRITE: wrote 7 bytes, 0 bytes left. |<4>| REC[0xf5fec0]: Sent Packet[2] Alert(21) in epoch 0 and length: 7 *** Handshake has failed GnuTLS error: An illegal TLS extension was received. |<4>| REC[0xf5fec0]: Start of epoch cleanup |<4>| REC[0xf5fec0]: End of epoch cleanup |<4>| REC[0xf5fec0]: Epoch #0 freed |<4>| REC[0xf5fec0]: Epoch #1 freed 1 dkg@alice:~$ So the server is sending the "Supported Elliptic Curves" extension, which should only be sent by the client: https://tools.ietf.org/html/rfc4492#section-5.1 lib/ext/ecc.c:95 shows the assertion: 0 dkg@alice:~/src/gnutls/gnutls$ cat -n lib/ext/ecc.c | head -n 100 | tail -n 26 75 /* 76 * In case of a server: if a SUPPORTED_ECC extension type is received then it stores 77 * into the session security parameters the new value. The server may use gnutls_session_certificate_type_get(), 78 * to access it. 79 * 80 * In case of a client: If a supported_eccs have been specified then we send the extension. 81 * 82 */ 83 static int 84 _gnutls_supported_ecc_recv_params (gnutls_session_t session, 85 const uint8_t * data, size_t _data_size) 86 { 87 int new_type = -1, ret, i; 88 ssize_t data_size = _data_size; 89 uint16_t len; 90 const uint8_t* p = data; 91 92 if (session->security_parameters.entity == GNUTLS_CLIENT) 93 { 94 /* A client shouldn't receive this extension */ 95 return gnutls_assert_val(GNUTLS_E_RECEIVED_ILLEGAL_EXTENSION); 96 } 97 else 98 { /* SERVER SIDE - we must check if the sent supported ecc type is the right one 99 */ 100 if (data_size < 2) 0 dkg@alice:~/src/gnutls/gnutls$ Maybe GnuTLS should be more permissive here, and just ignore this extension (maybe emitting a warning) if it comes from the server? > I had to switch to gnutls >= 3.2.1 since it is the first one supporting > the ECC cypher, which appears to be TLS extension required by this > server (but not by github.com, apparently). However I get an even > weirder error: This shouldn't be necessary; testing from another machine, i was able to connect with gnutls-cli from version 2.12.20, which doesn't support ECC at all, and i was also able to connect with a priority string that disables all ECC, which apparently means the buggy server won't try to send the extension it wasn't supposed to send in the first place: gnutls --priority NORMAL:-CURVE-ALL siscog.campfirenow.com hth, --dkg
pgpH5NJVRqH4a.pgp
Description: PGP signature
_______________________________________________ Gnutls-help mailing list [email protected] http://lists.gnupg.org/mailman/listinfo/gnutls-help
