[PATCH] https: support tls sni (server name indication) for https urls (issue3090)

[Alex Orange]

Thank you, that explains a lot. I'd forgotten about the silly naming of
SSLv23. That makes me more encouraged that it would be a good idea to use
create_default_context. I think certain of the other changes I see
mentioned like what encryption suites are supported should be more heavily
vetted before we go further into this. It sounds like it's saying RC4 isn't
supported, RC4 ofc isn't that great, but I'm not sure what usage it may
still have out there. I know google used to use it, though I notice they've
gone to AES128, so I can't give any specific examples any more then to say
such a change should be more heavily discussed. In summary, this all sounds
like a very good idea, but I think it needs more discussion and a better
understanding of any and all differences between what we have and what
create_default_context would give us.

As to the note about purpose, I fumbled what I was trying to say. The
ssl_wrap_socket function is also used for other things like the email
handler where it takes a key and cert file. I'm not sure what side effects
this purpose argument may have. Are you saying that it's basically
equivalent to the server_side boolean in wrap_socket, and if so, why does
SSLContext's wrap_socket still have the server_side boolean. All I'm saying
wrt purpose is that I don't have a firm understanding what the different
purposes actually do.

I didn't realize going into this that there was a code freeze coming up
soon, now that I am aware I would like to keep the changes to the absolute
minimum needed to support SNI in hopes that doing so will help it get in.

Alex

On Tue, Jan 13, 2015 at 10:36 AM, Antoine Pitrou <solipsis at pitrou.net>
wrote:

> On Tue, 13 Jan 2015 10:09:14 -0700
> Alex Orange <crazycasta at gmail.com> wrote:
> > Could you expand a little more on why create_default_context would be
> > any better? I'm looking to make a minimal change to the existing code,
> > which it looks like create_default_context would not be (having to
> > determine purpose for instance). Also, it sounds like the default
> > protocol version (PROTOCOL_SSLv23) is lower then what we want anyways.
>
> create_default_context() sets up-to-date security settings for ciphers
> and the like, so you don't have to choose them yourself. Going forward,
> it should be the preferred API to create client contexts, unless you
> have very special needs.
>
> As for PROTOCOL_SSLv23, it is a misunderstanding (or a misnaming :-)):
> PROTOCOL_SSLv23 will actually allow TLS 1.1 and 1.2, while
> PROTOCOL_TLSv1 doesn't.
>
> As for the purpose, it is documented:
>
>  Purpose.SERVER_AUTH
>
>     Option for create_default_context() and
>     SSLContext.load_default_certs(). This value indicates that the
>     context may be used to authenticate Web servers (therefore, it will
>     be used to create client-side sockets).
>
> Regards
>
> Antoine.
>
>
> _______________________________________________
> Mercurial-devel mailing list
> Mercurial-devel at selenic.com
> http://selenic.com/mailman/listinfo/mercurial-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://selenic.com/pipermail/mercurial-devel/attachments/20150113/493ef873/attachment.html>