Re: [openssl-users] BEAST and SSL_OP_DONT_INSERT_EMPTY_FRAGMENTS
Thanks for your comments - much appreciated. What is exactly the poodle patch and how doe sit come into providing some form of protection against the BEAST attack ? -- View this message in context: http://openssl.6102.n7.nabble.com/BEAST-and-SSL-OP-DONT-INSERT-EMPTY-FRAGMENTS-tp59291p59743.html Sent from the OpenSSL - User mailing list archive at Nabble.com. ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] BEAST and SSL_OP_DONT_INSERT_EMPTY_FRAGMENTS
What about 3DES with appropriate IV, downgrade and replay countermeasures, what exactly is wrong with those ciphers that is beyond salvage?(By salvage I mean significantly better than plain text when talking to clients that don't support anything more modern, such as certain Microsoft systems). I don't know. I am not a cryptographer, and I try not to come across as if I were. There are no safe SSL3 ciphers is something several cryptographers and other members of the security community, have said loudly and often. ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] BEAST and SSL_OP_DONT_INSERT_EMPTY_FRAGMENTS
Try this as a starting point: https://security.ias.edu/poodle-and-beast-isnt-love-story-sslv3-cipher-vulnerability ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] BEAST and SSL_OP_DONT_INSERT_EMPTY_FRAGMENTS
On 19/08/2015 16:37, Salz, Rich wrote: Try this as a starting point: https://security.ias.edu/poodle-and-beast-isnt-love-story-sslv3-cipher-vulnerability ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users That's just some guy pontificating before the SCSV countermeasure was available. Absolutely no technical arguments. The list of sources is equally random and non-detailed as to why there is nothing salvageable. For instance, one is a link where Bodo Moeller explains why something like the _EMPTY_FRAGMENTS countermeasure is needed for the IV issue. I know a lot of people said the sky was falling, I am trying to remember why. Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. http://www.wisemo.com Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10 This public discussion message is non-binding and may contain errors. WiseMo - Remote Service Management for PCs, Phones and Embedded ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] BEAST and SSL_OP_DONT_INSERT_EMPTY_FRAGMENTS
On 19/08/2015 00:26, Salz, Rich wrote: There are *no* secure SSLv3 ciphers. If you need to support it (for legacy clients), then best you can do is use the poodle patch, the SCSV indicator which will at least prevents clients that are capable of more from being downgraded. What about 3DES with appropriate IV, downgrade and replay countermeasures, what exactly is wrong with those ciphers that is beyond salvage?(By salvage I mean significantly better than plain text when talking to clients that don't support anything more modern, such as certain Microsoft systems). Specifically: If the SSL library aborts session on first bad decryption, the adversary gets only one use of the padding oracle per key. Shouldn't this kill off those attacks. With 1/n-1 or 0/n splitting, the predictable IV issue should be reasonably mitigated.(Hence the prior discussion of the need to not disable thatvia SSL_OP_ALL). With export-RSA and export-DH properly disabled, attempts to downgrade to 40/56 bit symmetric keys should be detected, or is there a bug in the way strong RSA/DSA keys are used to authenticate the negotiation that would allow a downgradeto downgrade its own check? With SCSV handling enabled, shouldn't that prevent downgrade-via-browser-retry attacks (Poodle)? Except of cause with browsers that lack the feature. Which attack scenario did I forget? Of cause it is more safe to insist that everybody else uses only TLS 1.2 with ECDH, AES and SHA-2, but I think that wold rule out too many clients in practice. Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. http://www.wisemo.com Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10 This public discussion message is non-binding and may contain errors. WiseMo - Remote Service Management for PCs, Phones and Embedded ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] BEAST and SSL_OP_DONT_INSERT_EMPTY_FRAGMENTS
Does this mean, since the 'no insert fragments' is part of SSL_OP_ALL, that OpenSSL is BEAST-proof since some time regarding it's use of TLS 1.0 and SSL 3.0 ? Thanks. -- View this message in context: http://openssl.6102.n7.nabble.com/BEAST-and-SSL-OP-DONT-INSERT-EMPTY-FRAGMENTS-tp59291p59732.html Sent from the OpenSSL - User mailing list archive at Nabble.com. ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] BEAST and SSL_OP_DONT_INSERT_EMPTY_FRAGMENTS
Does this mean, since the 'no insert fragments' is part of SSL_OP_ALL, that OpenSSL is BEAST-proof since some time regarding it's use of TLS 1.0 and SSL 3.0 ? No. ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] BEAST and SSL_OP_DONT_INSERT_EMPTY_FRAGMENTS
OK. So this means that the SSL_OP_DONT_INSERT_EMPTY_FRAGMENTS is not the solution for the BEAST attack. Is there a solution while keeping TLS 1.0 and SSL v3.0 ? Thanks. -- View this message in context: http://openssl.6102.n7.nabble.com/BEAST-and-SSL-OP-DONT-INSERT-EMPTY-FRAGMENTS-tp59291p59734.html Sent from the OpenSSL - User mailing list archive at Nabble.com. ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] BEAST and SSL_OP_DONT_INSERT_EMPTY_FRAGMENTS
On 18/08/2015 23:06, jonetsu wrote: OK. So this means that the SSL_OP_DONT_INSERT_EMPTY_FRAGMENTS is not the solution for the BEAST attack. Is there a solution while keeping TLS 1.0 and SSL v3.0 ? Thanks. The solution is NOT setting SSL_OP_DONT_INSERT_EMPTY_FRAGMENTS and hoping the other end doesn't have whatever bug caused the OpenSSL team to disable the workaround by default. Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. http://www.wisemo.com Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10 This public discussion message is non-binding and may contain errors. WiseMo - Remote Service Management for PCs, Phones and Embedded ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] BEAST and SSL_OP_DONT_INSERT_EMPTY_FRAGMENTS
There are *no* secure SSLv3 ciphers. If you need to support it (for legacy clients), then best you can do is use the poodle patch, the SCSV indicator which will at least prevents clients that are capable of more from being downgraded. ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] BEAST and SSL_OP_DONT_INSERT_EMPTY_FRAGMENTS
On 22/07/2015 14:12, jonetsu wrote: Hello, Our Nessus version 6.4.1 is detecting a BEAST vulnerability against OpenSSL 1.0.1e. The source code defines SSL_OP_DONT_INSERT_EMPTY_FRAGMENTS as 0x0800L and several tests are made for this value in the code. The CHANGES mentions though that this had some side effects, the option now being part of SSL_OP_ALL. It would look like, from the scan, that the fragments are not enabled by default, could it be ? Yep, for some silly reason, SSL_OP_DONT_INSERT_EMPTY_FRAGMENTS was/is included in the default value SSL_OP_ALL. This is in the same header as SSL_OP_DONT_INSERT_EMPTY_FRAGMENTS. The proper solution, as just about everybody knows by now would have been to insert 1-byte fragments (known as the 1/n-1 solution) which some other SSL/TLS implementations do. Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. http://www.wisemo.com Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10 This public discussion message is non-binding and may contain errors. WiseMo - Remote Service Management for PCs, Phones and Embedded ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
[openssl-users] BEAST and SSL_OP_DONT_INSERT_EMPTY_FRAGMENTS
Hello, Our Nessus version 6.4.1 is detecting a BEAST vulnerability against OpenSSL 1.0.1e. The source code defines SSL_OP_DONT_INSERT_EMPTY_FRAGMENTS as 0x0800L and several tests are made for this value in the code. The CHANGES mentions though that this had some side effects, the option now being part of SSL_OP_ALL. It would look like, from the scan, that the fragments are not enabled by default, could it be ? Thanks. ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
