Hi,
> But now I go back to lib/curl reasoning and how TLS extensions as a
> whole and each particular TLS extension in particular should affect
> libcurl or curl users. In other words how the TLS client extensions
> should or could be used in libcurl and curl.

> And this is completely different than asking for an encrypted
> connection and getting an unsecured one ;-)
think of this situation which is probably the most common one which might happen in real world:
- the user wants to download / connect / whatever to https://sni.vanilla.com/
- curl wants to connect and verify the cert
--- without SNI the user receives the wrong cert, and thus curl cant verify the cert and refuses to connect, and if the user still wants to proceed he _has_ to use the --insecure option.
--- with SNI the proper cert is selected, and provided that the CA is known to curl the verification succeeds.

I think this sample makes clear that in fact SNI makes things more secure rather than less because the user can now also verify SNI hosts rather than beeing forced to use --insecure mode.

Guen.
Received on 2008-02-14