[issue33062] ssl_renegotiate() doesn't seem to be exposed

2018-08-02 Thread Fantix King


Change by Fantix King :


--
nosy: +fantix

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue33062] ssl_renegotiate() doesn't seem to be exposed

2018-08-02 Thread Fantix King


Change by Fantix King :


--
keywords: +patch
pull_requests: +8125
stage:  -> patch review

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue33062] ssl_renegotiate() doesn't seem to be exposed

2018-03-14 Thread Nathaniel Smith

Nathaniel Smith  added the comment:

> 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.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue33062] ssl_renegotiate() doesn't seem to be exposed

2018-03-13 Thread Vitaly Kruglikov

Vitaly Kruglikov  added the comment:

> 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.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue33062] ssl_renegotiate() doesn't seem to be exposed

2018-03-13 Thread Nathaniel Smith

Nathaniel Smith  added the comment:

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

--
nosy: +njs

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue33062] ssl_renegotiate() doesn't seem to be exposed

2018-03-13 Thread Martin Panter

Martin Panter  added the comment:

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  (use the lower-case "r" 
command). More recently I did a similar thing with "s_client", where you have 
to use capital "R".

--
nosy: +martin.panter

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue33062] ssl_renegotiate() doesn't seem to be exposed

2018-03-13 Thread Christian Heimes

Christian Heimes  added the comment:

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.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue33062] ssl_renegotiate() doesn't seem to be exposed

2018-03-13 Thread Vitaly Kruglikov

Vitaly Kruglikov  added the comment:

> 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.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue33062] ssl_renegotiate() doesn't seem to be exposed

2018-03-13 Thread Christian Heimes

Christian Heimes  added the comment:

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.

--
type: behavior -> enhancement
versions:  -Python 2.7, Python 3.4, Python 3.5, Python 3.6, Python 3.7

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue33062] ssl_renegotiate() doesn't seem to be exposed

2018-03-12 Thread Vitaly Kruglikov

New submission from Vitaly Kruglikov :

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.

--
assignee: christian.heimes
components: SSL
messages: 313706
nosy: christian.heimes, vitaly.krug
priority: normal
severity: normal
status: open
title: ssl_renegotiate() doesn't seem to be exposed
type: behavior
versions: Python 2.7, Python 3.4, Python 3.5, Python 3.6, Python 3.7, Python 3.8

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com