classification
Title: Hostname validation is False by default in imaplib
Type: security Stage: needs patch
Components: email Versions: Python 3.7
process
Status: open Resolution:
Dependencies: Superseder:
Assigned To: christian.heimes Nosy List: barry, christian.heimes, maciej.szulik, mcepl, r.david.murray
Priority: normal Keywords:

Created on 2016-09-30 20:59 by maciej.szulik, last changed 2018-04-21 19:11 by mcepl.

Messages (3)
msg277772 - (view) Author: Maciej Szulik (maciej.szulik) * (Python triager) Date: 2016-09-30 20:59
According to David [1] hostname validation should be True by default for the imaplib, my tests clearly show something different. Additionally he states you Christian were doing so, that's why I'm opening this not to forget about the problem and discuss eventually what should happen.


[1] http://bugs.python.org/review/25591/diff/16398/Lib/test/test_imaplib.py#newcode451
msg315574 - (view) Author: Matej Cepl (mcepl) * Date: 2018-04-21 18:31
I do agree with http://legacy.python.org/dev/peps/pep-0476/#other-protocols:

This PEP only proposes requiring this level of validation for HTTP clients, not for other protocols such as SMTP.

This is because while a high percentage of HTTPS servers have correct certificates, as a result of the validation performed by browsers, for other protocols self-signed or otherwise incorrect certificates are far more common.

With HTTP (and thanks to Let’s Encrypt) the situation seems to be really good, and most publicly accessible webserver will hopefully have soon good signed certificates, but I am afraid that with other servers (and especially but certainly not limited to IMAP servers) there are just too many self-signed certificates (or ones signed by suspicious internal CAs) in various internal email servers, that changing defaults would do more harm than good, I am afraid. Also, arguing about defaults is the way of The Waste of Time, so I will try to limit myself just to this one comment on this bug.
msg315579 - (view) Author: Matej Cepl (mcepl) * Date: 2018-04-21 19:11
See also issue 33327.
History
Date User Action Args
2018-04-21 19:11:49mceplsetmessages: + msg315579
2018-04-21 18:31:58mceplsetnosy: + mcepl
messages: + msg315574
2016-09-30 20:59:42maciej.szulikcreate