[openssl-users] parse tlsext error in response to client hello
Dear all -- Trying to debug a failing TLS negotiation. Is the following (possibly erroneous) "supported point formats extension" the cause of openssl's "parse tlsext" error? 00 0b 00 01 00where 000b == the extension type (ec point formats), 0001 == the length (1 byte), and 00 == a zero-length ec point formats list. The example in RFC 4492 (section 5.1.2) is: A client that can parse only the uncompressed point format (value 0) includes an extension consisting of the following octets; note that the first two octets indicate the extension type (Supported Point Formats Extension): 00 0B 00 02 01 00 And further, section 5.1 of the same RFC explicitly states "if the Supported Point Formats Extension is indeed sent, it MUST contain the value 0 (uncompressed) as one of the items in the list of point formats." For reference, here is the complete "SSL record" of the client hello taken from a packet capture: 16 03 01 00 5c 01 00 00 58 03 01 56 a6 52 fa a0 0010 7e e3 1d 40 16 89 dd 23 2a 92 dd b5 77 c5 d3 19 0020 10 82 07 9a 4f de 54 1e 69 c7 c4 00 00 1e 00 2f 0030 00 35 00 04 00 05 00 09 00 0a 00 03 00 08 c0 13 0040 c0 14 c0 09 c0 0a 00 33 00 39 00 16 01 00 00 11 0050 00 0a 00 08 00 06 00 17 00 18 00 19 00 0b 00 01 0060 00 Many Thanks! --OLW P.S.: Apologies for the enormous footer that gets tacked on below here. -- This e-mail and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this e-mail in error please notify the sender immediately and delete this e-mail from your system. Please note that any views or opinions presented in this e-mail are solely those of the author and do not necessarily represent those of Ricardo (save for reports and other documentation formally approved and signed for release to the intended recipient). Only Ricardo's authorized representatives may enter into legally binding obligations on behalf of Ricardo. Ricardo may monitor outgoing and incoming e-mails and other telecommunications systems. By replying to this e-mail you give consent to such monitoring. The recipient should check e-mail and any attachments for the presence of viruses. Ricardo accepts no liability for any damage caused by any virus transmitted by this e-mail. "Ricardo" means Ricardo Inc. and its affiliated companies. --'. ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
[openssl-users] parse tlsext error in response to client hello
Dear all -- Trying to debug a failing TLS negotiation. Is the following (possibly erroneous) "supported point formats extension" the cause of openssl's "parse tlsext" error? 00 0b 00 01 00where 000b == the extension type (ec point formats), 0001 == the length (1 byte), and 00 == a zero-length ec point formats list. The example in RFC 4492 (section 5.1.2) is: A client that can parse only the uncompressed point format (value 0) includes an extension consisting of the following octets; note that the first two octets indicate the extension type (Supported Point Formats Extension): 00 0B 00 02 01 00 And further, section 5.1 of the same RFC explicitly states "if the Supported Point Formats Extension is indeed sent, it MUST contain the value 0 (uncompressed) as one of the items in the list of point formats." For reference, here is the complete "SSL record" of the client hello taken from a packet capture: 16 03 01 00 5c 01 00 00 58 03 01 56 a6 52 fa a0 0010 7e e3 1d 40 16 89 dd 23 2a 92 dd b5 77 c5 d3 19 0020 10 82 07 9a 4f de 54 1e 69 c7 c4 00 00 1e 00 2f 0030 00 35 00 04 00 05 00 09 00 0a 00 03 00 08 c0 13 0040 c0 14 c0 09 c0 0a 00 33 00 39 00 16 01 00 00 11 0050 00 0a 00 08 00 06 00 17 00 18 00 19 00 0b 00 01 0060 00 Many Thanks! --OLW -- This e-mail and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this e-mail in error please notify the sender immediately and delete this e-mail from your system. Please note that any views or opinions presented in this e-mail are solely those of the author and do not necessarily represent those of Ricardo (save for reports and other documentation formally approved and signed for release to the intended recipient). Only Ricardo's authorized representatives may enter into legally binding obligations on behalf of Ricardo. Ricardo may monitor outgoing and incoming e-mails and other telecommunications systems. By replying to this e-mail you give consent to such monitoring. The recipient should check e-mail and any attachments for the presence of viruses. Ricardo accepts no liability for any damage caused by any virus transmitted by this e-mail. "Ricardo" means Ricardo Inc. and its affiliated companies. --'. ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] parse tlsext error in response to client hello
On 25/01/16 20:02, Wieck, Owen wrote: > Dear all -- > > Trying to debug a failing TLS negotiation. Is the following (possibly > erroneous) "supported point formats extension" the cause of openssl's "parse > tlsext" error? Yes. I copied your record below and pushed it through OpenSSL to recreate the error. It is indeed failing on the parsing of the supported point formats extension for precisely the reason you have specified. OpenSSL automatically rejects a zero length point formats extension. Matt > > 00 0b 00 01 00where 000b == the extension type (ec point formats), 0001 == > the length (1 byte), and 00 == a zero-length ec point formats list. > > The example in RFC 4492 (section 5.1.2) is: > > A client that can parse only the uncompressed point format (value 0) >includes an extension consisting of the following octets; note that >the first two octets indicate the extension type (Supported Point >Formats Extension): > > 00 0B 00 02 01 00 > > And further, section 5.1 of the same RFC explicitly states "if the Supported > Point Formats Extension is indeed sent, it MUST contain the value 0 > (uncompressed) as one of the items in the list of point formats." > > For reference, here is the complete "SSL record" of the client hello taken > from a packet capture: > > 16 03 01 00 5c 01 00 00 58 03 01 56 a6 52 fa a0 > 0010 7e e3 1d 40 16 89 dd 23 2a 92 dd b5 77 c5 d3 19 > 0020 10 82 07 9a 4f de 54 1e 69 c7 c4 00 00 1e 00 2f > 0030 00 35 00 04 00 05 00 09 00 0a 00 03 00 08 c0 13 > 0040 c0 14 c0 09 c0 0a 00 33 00 39 00 16 01 00 00 11 > 0050 00 0a 00 08 00 06 00 17 00 18 00 19 00 0b 00 01 > 0060 00 > > Many Thanks! > > --OLW > > P.S.: Apologies for the enormous footer that gets tacked on below here. > -- > This e-mail and any files transmitted with it are confidential and intended > solely for the use of the individual or entity to whom they are > addressed. If you have received this e-mail in error please notify the sender > immediately and delete this e-mail from your system. > Please note that any views or opinions presented in this e-mail are solely > those of the author and do not necessarily represent those > of Ricardo (save for reports and other documentation formally approved and > signed for release to the intended recipient). Only Ricardo's > authorized representatives may enter into legally binding obligations on > behalf of Ricardo. Ricardo may monitor outgoing and incoming e-mails and > other telecommunications systems. By replying to this e-mail you give consent > to such monitoring. The recipient should check e-mail and > any attachments for the presence of viruses. Ricardo accepts no liability for > any damage caused by any virus transmitted by this e-mail. > "Ricardo" means Ricardo Inc. and its affiliated companies. > --'. > ___ > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
[openssl-users] Forthcoming OpenSSL releases
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Forthcoming OpenSSL releases The OpenSSL project team would like to announce the forthcoming release of OpenSSL versions 1.0.2f, 1.0.1r. These releases will be made available on 28th January between approx. 1pm and 5pm (UTC). They will fix two security defects, one of "high" severity affecting 1.0.2 releases, and one "low" severity affecting all releases. Please see the following page for further details of severity levels: https://www.openssl.org/policies/secpolicy.html Please also note that, as per our previous announcements, support for 1.0.0 and 0.9.8 releases ended on 31st December 2015 and are no longer receiving security updates. Support for 1.0.1 will end on 31st December 2016. Yours The OpenSSL Project Team -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQEcBAEBCAAGBQJWpgNkAAoJEAEKUEB8TIy9QcwH/3C7y700FjGjDBcNMcVO++GU 81cs87VqsoziuMSU9Sx8XlDWA8tH5JWXpES4+p9iWdKbks+2E0EahVZVaS5yDaLM LY6MaUM2Pucmrd/I7mvQ02AzzMWEUrFlbk1GtFVjU7IkYc1/ZOZLhjM6H0X8M8lO 5kvqpgWTGV5lMCJdOQLr/eIGIdGTy5Xqerm3Qz/nzvhbwaOu5pjvq0eub8AWbPb3 wwdB4GIKW4XaU7YAJl61o8jNeVoy/kMTfZmZYEefQzXf/1JYO2p8oqCMTIEUrSoN P7sT2d2DpjQvrK3j8MsIPMYUHLhxZt+MJ2+wuOLyznkPTdEIV+ylr6q0I74Wv1Q= =gzHe -END PGP SIGNATURE- ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
