[Python-Dev] Backwards compatibility after certificate autovalidation

[Jim J. Jewett]

Summary:  There needs to be a simple way to opt out at install time.
It would be far better to offer more fine-grained control, but leaving
that better solution to downstream is acceptable.


On 3 September 2014 01:19, Antoine Pitrou <solipsis at pitrou.net> wrote:

> RFC 2818 (HTTP over TLS) has the following language in section 3.1:

>> If the hostname is available, the client MUST check it against the
>> server's identity as presented in the server's Certificate message,
>> in order to prevent man-in-the-middle attacks.

>> If the client has external information as to the expected identity of
>> the server, the hostname check MAY be omitted.

This second case is pretty common, in my experience.  I still see it on
the public internet, but mismatches are almost the expected case on the
intranet, and many installation guides begin by saying to ignore the
security warnings.

I think it best not to name my employer in this context, but I work for
an IT firm large enough that you've heard of it.  As bad as our internal
situation is, it is still better than a typical client's infrastructure,
except that clients often have fewer surfaces to expose in the first place.

Internal websites and applications tend to have information that "needs
protection" only because saying otherwise requires a long bureaucratic
process with little payoff.  (Also true at many clients.)  Nick has
already posted a subset of the reasons why a site may be "signed" with
a certificate that is self-signed, expired, and/or limited to the wrong
hostname/subdomain.  

In the long run, I agree that it is better to default to secure.  But
in the short and medium term, there has to be a workaround, and I would
prefer that the simplest workaround not be "retire the application, and
don't use python again."

I believe that the minimal acceptable workaround is that the Release
Notes have an URL pointing to an install-time recipe telling the admin
how to change the default back globally.

Examples of good enough:
    "Add this file to site-packages" 
    "Add this environment variable with this setting" 
    "Add this command line switch to your launch script" 

Examples of not good enough:    
    "Edit your application to change ..."
    "Edit your system store ..." (affecting more than python)

Obviously, it would be great to offer finer control, so that the
stricter default can be used when it is OK.  (Per installation?  Per
application?  Per run?  Per domain?  Per protocol?  Per certificate?
Per rejection reason?  Treat anything in subdomain1.example.com as
valid for hostname.example.com?  Self-signing is OK for this IP range?)
I would be pleasantly surprised if this level of API can even be
standardized in time, and I agree that it is reasonable to leave it
to 3rd party modules and downstream distributions.

But I think Python itself should provide at least the single big
hammer -- and that hammer should be something that can be used once
at installation time (perhaps by changing the launch script), instead
of requiring user interaction.


-jJ

--

If there are still threading problems with my replies, please
email me with details, so that I can try to resolve them.  -jJ