Repository navigation
ssl.wrap_ssl will fail on do_handshake if default parameters are supplied by user #74474
Description
| BPO | 30288 |
|---|---|
| Nosy | @tiran, @DenSA-Inc |
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
assignee = 'https://github.com/tiran'
closed_at = <Date 2017-05-06.00:43:24.956>
created_at = <Date 2017-05-05.23:38:45.315>
labels = ['expert-SSL', 'type-crash']
title = 'ssl.wrap_ssl will fail on do_handshake if default parameters are supplied by user'
updated_at = <Date 2017-05-06.00:43:24.946>
user = 'https://github.com/DenSA-Inc'bugs.python.org fields:
activity = <Date 2017-05-06.00:43:24.946>
actor = 'botter'
assignee = 'christian.heimes'
closed = True
closed_date = <Date 2017-05-06.00:43:24.956>
closer = 'botter'
components = ['SSL']
creation = <Date 2017-05-05.23:38:45.315>
creator = 'botter'
dependencies = []
files = []
hgrepos = []
issue_num = 30288
keywords = []
message_count = 2.0
messages = ['293146', '293147']
nosy_count = 2.0
nosy_names = ['christian.heimes', 'botter']
pr_nums = []
priority = 'normal'
resolution = None
stage = 'resolved'
status = 'closed'
superseder = None
type = 'crash'
url = 'https://bugs.python.org/issue30288'
versions = ['Python 3.4']
Activity
DenSA-Inc commentedon May 5, 2017
After a big problem with the newest ejabberd-version and sleekxmpp I located the problem in ssl.wrap_socket. When called with no parameters the later do_handshake (method of ssl.SSLSocket) fails with an exception. When called with keyword-parameters which match the default values (except for do_handshake_on_connect), do_handshake will fail when called after that. Once I have time I will edit this post to add the required information here, but for now I refer to the issue filed on github: fritzy/SleekXMPP#452
The important information is in comments 2 and 3.
DenSA-Inc commentedon May 6, 2017
I just realised that the server stopped supporting TLS-v1.0 and the code still tried to establish a TLS-v1.0-connection. Yet the server responded with TLS-v1.2. So no bug here.