[vlc-devel] add support for https video streaming from websites with untrusted SSL certificates

[Rémi Denis-Courmont]

On Mon, 20 Dec 2010 23:54:26 +0200, Juho Vähä-Herttua <juhovh at iki.fi>
wrote:
> On 20.12.2010, at 23.06, Rémi Denis-Courmont wrote:
>> There is no point in using TLS if you don't verify the certificates. In
>> fact, Mozilla is making it quite hard to ignore the certificate errors
>> these days. That's not an accident.
> 
> I agree with pretty much everything said in the email, but this part is
> crap.

Ok, there is a difference. A passive eaves-dropper cannot attack a TLS
stream if the server certificate is unverified but valid:

> Even without certificate verification TLS is a lot better than plain
> HTTP, and sniffing the traffic would require a successful active MITM
> attack. Using TLS without certificate validation (even if it's just plain
> DH key exchange without signatures) prevents passive sniffers from
reading
> the traffic and possibly finding out sensitive data. (HTTP session
cookies)

However...

> I'm mostly referring to stuff like unencrypted wireless networks and the
> attacks like firesheep that became quite popular recently.

That's a counter-example. On typical unencrypted wireless networks, such as
most commercial or unregulated WiFi access points, anyone can be an active
man-in-the-middle. You can trivially attack the MAC layer, or the DNS
service.

> Yeah, encryption
> without verification is not very effective, because anyone who gets in
the
> middle and can block the packets can also replace the certificates.
Calling
> it pointless is oversimplifying things.

Sure. But the underlying point is that most users do not know how when and
when not to ignore certificate errors. The --no-tls-cert-check option (or
whatever its name was) was not solving that problem to any meaningful
extent. I actually think that rejecting invalid certificates is better than
having that short-sighted option. At least lazy and incompetent admins
cannot tell their VLC users to just disable the security.

> I have no clue about what kind of cipher suites VLC supports in its TLS
> implementation, but I'd recommend using simple DHE cipher suites without
> the certificate if it's not going to be verified anyway.

That does not make sense for HTTP. For HTTP, you are supposed to match the
domain name with the certificate. This is meaningless if the key exchange
is anonymous. And there is no secure way to determine whether a given
website is, or is not anonymous. Thus, in practice, HTTP servers and HTTP
clients do not allow anonymous key exchange. And hence websites do not use
that mode of TLS, even those with invalid certificates.

So in theory, this is not really any better than tolerating invalid
certificates. And in practice, this would not even work because real-life
software would not allow it.

> Simply ignoring
> the certificate validation is not right, which I believe is Rémi's
point.
> I don't see why using VLC without certificate validation shouldn't be
> possible in some way, though.

Using DHE would make sense for an (hypothetical) protocol-over-TLS that
specifies its use. It does not make sense for standard HTTP.

-- 
Rémi Denis-Courmont
http://www.remlab.net
http://fi.linkedin.com/in/remidenis