<div dir="ltr"><div>If I could summarize this discussion (please correct me if I am wrong):</div><div><br></div><div>1. Status Quo</div><div><br></div><div>   All existing versions of Python are unsecure by default</div><div>
   because by not doing SSL hostname verification,</div><div>   libraries which wrap sockets with SSLContext</div><div>   allow SSL MITM (man-in-the-middle) with no warning.</div><div><br></div><div>   Christian Heimes has introduced ss.create_default_context for 3.4</div>
<div><br></div><div>   Donald Stuft is proposing that hostname verification should be</div><div>   the default behavior in future versions of Python;</div><div>   such as Python 3.4,</div><div>   ideally as soon as possible.</div>
<div><br></div><div>   python-dev has been resistant to preventing SSL MITM by default</div><div>   because humans, pypi:keyring, and pypi:certifi</div><div><br></div><div><br></div><div>2. Generalizations about end-users:</div>
<div><br></div><div>   * corporate users aren't susceptible to MITM because perimeter</div><div><br></div><div>     * fallacious on all accounts</div><div>     * mismatched metaphors abound</div><div><br></div><div>   * nobody knows how to add self-signed CA certs to their chains</div>
<div><br></div><div>     * Agreed.</div><div><br></div><div>   * most people haven't / aren't going to read the docs:</div><div>     <a href="http://docs.python.org/3/library/ssl.html#verifying-certificates">http://docs.python.org/3/library/ssl.html#verifying-certificates</a></div>
<div><br></div><div>     A **warning::** would probably be appropriate</div><div><br></div><div>     (and a big red warning box has been added to the 3.3 docs)</div><div><br></div><div>     It could also say "PYTHON DOES NOT VALIDATE SSL CERTIFICATES BY DEFAULT"</div>
<div><br></div><div>   * most people don't realize / have modification rights / have the</div><div>     ability to submit patches upstream; either to</div><div><br></div><div>     * set CERT_REQUIRED for every connection</div>
<div>     * set (a forthcoming) CERT_NOVALIDATE</div><div><br></div><div>   * people who complain about breaking security defaults</div><div>     which allow MITM are most relevant</div><div><br></div><div>   * "it doesn't work on my SOHO router"</div>
<div><br></div><div>   * people would need to understand how Python</div><div>     (and many other languages' SSL implementations)</div><div>     is less secure than current browsers</div><div><br></div><div>   * people don't read "What's New"; distributions test and upgrade their</div>
<div>     interpreter for them</div><div><br></div><div>   * some people are aware that third-party libraries requests and urllib3</div><div>     do SSL hostname validation by default, now, with Python 2</div><div><br></div>
<div><br></div><div>3. Compatibility</div><div><br></div><div>   There could be a PYTHONSSLNOVALIDATE environment variable:</div><div><br></div><div>   * +1 : This would allow workarounds for applications which cannot be</div>
<div>     updated</div><div>   * -1 : This is not preferable because PYTHONHASHSEED</div><div><br></div><div><br></div><div>4. Chain management</div><div><br></div><div>   * It should be possible to update the cert chain</div>
<div>   * It could be easier to specify a different cert chain (?)</div><div>   * Python 3.4 now supports using the Windows cert chain</div><div>   * Pip does not yet support using the Windows cert chain</div><div>   * pypi:certifi adds the Mozilla Firefox keychain for Python 2 and 3</div>
<div>     (like requests and pip)</div><div><br></div><div><br></div><div>5. Deprecation</div><div><br></div><div>   * Should deprecate slowly (2017) because people would complain about</div><div>     having been secured against MITM (in their upgrade to Python 3.4)</div>
<div>   * Should not deprecate slowly because the status quo</div><div>     (insecure by default) is risky</div><div>   * Should add pending deprecation now (see CERT_NOVALIDATE NOP below)</div><div><br></div><div><br></div>
<div>6. Testing Responses</div><div><br></div><div>   * It's probably good to start testing downstream patches</div><div>     to Python 3.4 packages</div><div>   * The error message may be primed</div><div><br></div><div>
<br></div><div>My two cents:</div><div><br></div><div>* CERT_NOVALIDATE could/should be present now (if even as a no-op)</div><div>* 2to3 could/should add CERT_NOVALIDATE</div><div><br></div><div><br></div><div>Please feel free to add any, all, or none of this to the forthcoming PEP.</div>
<div><br></div><div>Thank you for addressing this issue.</div><div><br></div><div>(This is buried here because the mailman archive gzip hasn't yet updated with</div><div>the latest Message-Id to specify for In-Reply-To)</div>
<div><br></div></div><div class="gmail_extra"><br clear="all"><div>-- <br>Wes Turner</div>
<br><br><div class="gmail_quote">On Wed, Jan 22, 2014 at 12:46 PM, Brian Curtin <span dir="ltr"><<a href="mailto:brian@python.org" target="_blank">brian@python.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">On Wed, Jan 22, 2014 at 12:10 PM, John Yeuk Hon Wong<br>
<<a href="mailto:gokoproject@gmail.com">gokoproject@gmail.com</a>> wrote:<br>
> On 1/22/14 8:16 AM, Nick Coghlan wrote:<br>
>><br>
>> Which is exactly the way most non-web-specialists working inside the<br>
>> comfort of corporate and academic firewalls will react to a change that<br>
>> breaks their access to internal applications, where self-signed certs and<br>
>> improperly configured internal CAs are endemic (of course, that's assuming<br>
>> they're using HTTPS at all, which I admit is an optimistic assumption).<br>
><br>
> The number of people who are using 3.4+ in these environments is probably<br>
> very very low to be honest. I don't have a number to prove, but in that<br>
> environment people are more likely to still be using 2.6+. I think a<br>
> deprecation in 2.7+ would be nice, but forward we should just enable it by<br>
> default.<br>
><br>
> When requests changed property calls (e.g. requests.json) to callable<br>
> instead of an attribute(from requests.json to requests.json()), I was<br>
> shocked. I had to figure out by Googling it. I found out from github<br>
> issue....<br>
><br>
> I think a hard fail is somehow necessary.<br>
><br>
> Also, a lot of people overlook at deprecation warnings. They either don't<br>
> care or don't see it. I see a lot of deprecation warnings in the older<br>
> applications I write, but I can careless until it breaks. So as we moving<br>
> forward, we can break it. For those stuck behind, deprecation is the right<br>
> approach.<br>
<br>
</div>They're disabled by default, so a lot of people simply don't know they<br>
exist because they also don't read the documentation.<br>
<div class="HOEnZb"><div class="h5">_______________________________________________<br>
Python-Dev mailing list<br>
<a href="mailto:Python-Dev@python.org">Python-Dev@python.org</a><br>
<a href="https://mail.python.org/mailman/listinfo/python-dev" target="_blank">https://mail.python.org/mailman/listinfo/python-dev</a><br>
Unsubscribe: <a href="https://mail.python.org/mailman/options/python-dev/wes.turner%40gmail.com" target="_blank">https://mail.python.org/mailman/options/python-dev/wes.turner%40gmail.com</a><br>
</div></div></blockquote></div><br></div>