| msg313706 - (view) |
Author: Vitaly Kruglikov (vitaly.krug) |
Date: 2018-03-12 22:26 |
| I need to write a test for my client to make sure it's non-blocking ssl interactions are able to survive SSL renegotiation. However, I can't seem to find anything in our python ssl API that calls `SSL_renegotiate()` in order to force renegotiation. |
|
|
| msg313727 - (view) |
Author: Christian Heimes (christian.heimes) *  |
Date: 2018-03-13 08:03 |
| Since it's a feature request, I have changed the version number to 3.8. By the way, renegotiation is a problematic and has been replaced by rekeying in TLS 1.3. |
|
|
| msg313739 - (view) |
Author: Vitaly Kruglikov (vitaly.krug) |
Date: 2018-03-13 10:35 |
| > By the way, renegotiation is a problematic and has been replaced by rekeying in TLS 1.3 How can I trigger rekeying via python ssl? Many thanks. |
|
|
| msg313740 - (view) |
Author: Christian Heimes (christian.heimes) * |
Date: 2018-03-13 11:14 |
| You can't. Rekeying is not available yet. SSL_key_update() is only available with OpenSSL 1.1.1 and TLS 1.3. Both are still in beta phase. |
|
|
| msg313798 - (view) |
Author: Martin Panter (martin.panter) * |
Date: 2018-03-14 02:12 |
| I have also wanted to force renegotation for testing with Python. As a workaround, I have used the "openssl s_server" program, which I described at <https://bugs.python.org/issue25919#msg257508> (use the lower-case "r" command). More recently I did a similar thing with "s_client", where you have to use capital "R". |
|
|
| msg313799 - (view) |
Author: Nathaniel Smith (njs) * |
Date: 2018-03-14 03:08 |
| PyOpenSSL supports renegotiation, and I've used it for writing exactly this kind of test. Might be easier than wrapping a test harness around the 'openssl' command. For extra fun, openssl itself doesn't fully support renegotiation on duplex connections, even if your code works correctly: http://openssl.6102.n7.nabble.com/TLS-renegotiation-failure-on-receiving-application-data-during-handshake-td48127.html |
|
|
| msg313805 - (view) |
Author: Vitaly Kruglikov (vitaly.krug) |
Date: 2018-03-14 05:41 |
| > For extra fun, openssl itself doesn't fully support renegotiation on duplex connections ... The necessitated modification to the application protocol on that thread sounds like an OpenSSL cop-out. There is no good reason that OpenSSL shouldn't be able to cache incoming application data during the client-initiated handshake just as it does at other times. It should be able to cache the incoming pre-negotiation records, decoding them. The pending() check would inform the client that they need to reap the incoming data during the handshake too. |
|
|
| msg313807 - (view) |
Author: Nathaniel Smith (njs) * |
Date: 2018-03-14 06:04 |
| > an OpenSSL cop-out Perhaps, but they've been doing it this way for a decade+, and we're living in a time when other libraries like BoringSSL are flat-out removing renegotiation support, so good luck convincing them to fix things. Anyway, it's nothing to do with Python, just a friendly heads-up; I ran into this when trying to do renegotiation tests on my non-blocking code using the 'ssl' module and was *very* confused for a while until I realized it wasn't my code's fault at all. |
|
|