Re: SSL/TLS everywhere fail

[ Note I have not followed the discussion here, but was notified of
   my name having come up in this discussion, hence my reply here ]

Jacob Appelbaum wrote:

> On 12/6/15, Amos Jeffries <squid3@treenet.co.nz> wrote:
> > On 6/12/2015 11:59 a.m., Jacob Appelbaum wrote:
> >> On 12/5/15, Poul-Henning Kamp wrote:

> >> Some object to confidentiality, others to integrity and so on. A lack
> >> of action on this has ensured that some protocols stay unencrypted -
> >> an explicit goal of some of the bad actors who are present as agents
> >> of influence in this (and other!) standards body.
> >
> > Please do not equate TLS with encryption. Encryption is much bigger than
> > TLS. A fact that the "TLS everywhere" fanatics are constantly shouting
> > out with their insistence that anyone doing encryption in non-TLS
> > settings is Bad Thing.
>
> {HTTP,IMAP,POP} to {HTTP,IMAP,POP} with TLS makes for a transition
> from unencrypted to an encrypted connection. Other than with say, the
> null cipher, of course.

I think what was meant was "TLS offers encryption, but encryption can be
offered by much more than only TLS".

> The second part of your statement doesn't make sense to me and sounds
> like a straw man. I'd love to see a citation to better understand your
> view. In any case, I'm not saying whatever someone else may have said
> about encryption, so could you clarify?

I haven't seen that either. AFAIK, the "HTTPS Everywhere" people just want
all http to move to https and have https certificates be gratis. That is
a good goal and shows very clearly that non-EV certs are nothing more
than proving control of DNS(SEC) - and so people should just move to
use TLSA DNS records as the standard for DV certs, obsoleting industry
DV certs and "HTTPS Everywhere" along with it. I am looking forward to
the DNSSEC TLS extension that will make that move possible:

https://tools.ietf.org/html/draft-shore-tls-dnssec-chain-extension-02

> > (I know you are not thinking of protocols like DNSSEC, VPN, or VPE as
> > unencrypted, but the implication is there.)
>
> Huh? DNSSEC isn't encrypted and most VPNs are garbage encryption. The
> few that aren't are personally or professionally run by Paul Wouters
> and a handful of IETF people.  My deepest respect to them, by the way.

Thanks for the vote of confidence, but... :)

First, let me clarify that while I am and have been involved with some
pretty big VPN and Opportunistic Encryption deployments, I don't "run"
any of them and have no credentials to any large production VPN (no need
to confiscate or steal my laptop). My personal focus is on everyone
running their own OE VPNs - governments ensured we cannot trust vendors
or service providers to do crypto as a service.

You can find a (somewhat dated) write up of that at:
https://nohats.ca/wordpress/blog/2013/09/12/history-and-implementation-status-of-opportunistic-encryption-for-ipsec/

There are many types of VPNs out there that are safe, but indeed a
lot of them that are not. The ones that are not are usually either
obsolete/old versions (like L2TP/IPsec or even plain L2TP or PPTP)
or other non-standarised solutions that haven't seen much research
(openvpn and a bunch of SSL VPNs come to mind). And of course a bunch of
basement crypto of people who only run their own designs, often fatally
flawed with no expert reviews and based on today's vanity encryption
algorithm. If people run VPNs based on a random github repository and
a tweet, nothing can save them.

But I do think most SSL/TLS VPNs that use up to date TLS as their
transport are very secure. OpenConnect is trying to do the right thing
and has smart software engineers behind it.

But TLS VPNs are impractical when you're dealing with UDPinTCP or
TCPinTCP connections. There is a good reason ESP/IPsec was not built on
top of TCP. Once you hit congestion or packetloss, the usability of
your TLS VPN goes down really fast. Sending UDP packets over TCP means
it's not really UDP anymore. And there is of course the TCP-RST
Denial Of Service attack.

The only good reason I can think of for TLS VPNs is to break through
networks that block IKE/IPsec VPNs by either administrative policy or
(hotel) incompetence. In fact, that is why the ipsecme working group
wanted to standarize IKE over TCP for a while. The current draft for that
is https://tools.ietf.org/html/draft-pauly-ipsecme-tcp-encaps-00 but some
vendors (Checkpoint, Cisco, etc) already have their own implementation
of IKE over TCP to work around these broken networks.  I would recommend
these over TLS VPNs myself. Note while the draft technically is "IKE over
TCP" most implementations will ofcourse use port 443 and TLS, but only
to break out of a network - not for any kind of security or encryption.

> Then there are the ones that are safe
> from a technological point of view, but still vulnerable to government
> coercsion.

Yes, a real perception problem is that VPN service providers offer you
privacy. This is only true up to a point. It protects you from the
coffeeshop or your ISP, but not from the government that oversees this
VPN provider (or their domains, nameservers, cloudinstances, etc of
which usually at least one is under control of USG and thus secret NSLs)
Luckilly for those people, the vast majority of customers of these IPsec
based VPN services only use it to watch TV from a non-allowed geographic
region.

> Basically everyone else is out to sea on a raft of backdoored crypto,
> held together with SIGINT and denialism. Or they're using VPN
> protocols which aren't specified by the IETF, sadly.

Unfortunately, a lot of the "free software rebels" out there kneejerk
against standards organiations and end up designing their own without
the review required by a real community of experts. It also does not
help that the "cypherpunks" mailinglists are filled with the most
alienating kind of people that make it next to impossible to read the
good stuff in a sea of vile. Posting there requires a very thick skin.

IKE/IPsec had learned a lot from the mistakes of early SSL. And with
TLS 1.3 we see that TLS in turn seems to pick up on some of the IKE
properties. IKEv2 is finally seeing deployment, bringing some of the
much needed improvements to IKE/IPsec, similar to how TLS 1.3 brings
much needed improvements to TLS. Both are strong and have different
use cases. One protects a single network flow, the other protects all
communication between two hosts.  Since error reporting for thes two
use cases are very different, I think it's good that both protocols are
going to stick around for a while.

Paul

Received on Monday, 7 December 2015 16:52:50 UTC