> On 31 Jan 2017, at 09:56, Paul Moore <p.f.mo...@gmail.com> wrote: > > On 31 January 2017 at 09:19, Cory Benfield <c...@lukasa.co.uk> wrote: >> >> In general, it is unwise to mix trust stores. If you want to use your OS’s >> trust store, the best approach is to use the OS’s TLS stack as well. At >> least that way when a user says “It works in my browser”, you know it should >> work for you too. > > As a bystander (and an "end user" of this stuff) the message I'm > getting here is a bit worrying. To take a step back from the sysadmin > issues here, is the statement > > It's safe to use Python (either via the stdlib, or various 3rd > party libraries like requests) to access https URLs > > correct? I understand that "safe" is a complex concept here, but in > terms of promoting Python, I'd be using the term in the sense of "at > least as acceptable as using something like C# or Java" - in other > words I'm not introducing any new vulnerabilities if I argue for > Python over one of those languages?
My answer would be “Yes*”. The asterisk is that it works best when you understand how you are rooting your trust stores. On Linux, if you use your distro provided OpenSSL and its trust store it is as safe as the rest of your system. On macOS, if you use the system Python it is unsafe. If you use a Python compiled against Homebrew’s OpenSSL, it is safe, though it is only safe based on a snapshot in time (this is for boring Homebrew-related reasons that are nothing to do with Python). On Windows, it is safe, though potentially less functional. Requests is basically safe, though it is definitely possible. If you are trying to reach websites on the open web using Requests, that’s safe, subject to the criteria below. The answer gets murkier if you do substantial configuration of a trust database. If you have added or removed root certificates from a system trust store, or you have configured the trust database on a Windows or Apple machine, then it all gets murky fast. If you’ve only added or expanded trust then Python is still safe on all those platforms, it is just less functional. If you’ve removed trust then it is possible that a Python process will trust something that other processes on your machine will not. However, you should be aware that that’s basically the default state of being for TLS. Java is basically in the same place as Python today, but with the added fun of having a hand-rolled TLS implementation (JSSE). C# is a different story: the stdlib uses SSPI for certificate validation, which basically means SChannel *on Windows*. In the wider .NET ecosystem I have no idea how this is being done. So C# applications are Windows-native safe on Windows, and are a crapshoot elsewhere. For Java vs Python, I’d say we’re slightly ahead right now. Again, the long-term solution to this fix is to allow us to use SChannel and SecureTransport to provide TLS on the relevant platforms. This will also let people use GnuTLS or NSS or whatever other TLS implementations float their boat on other Unices. I’ll be bringing a draft PEP in front of python-dev sometime in the next month to start this work: if you’re interested, I recommend helping out with that process! Cory _______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
