Re: Adding Security Considerations regarding interception to p1

On Fri, Sep 20, 2013 at 9:30 AM, Willy Tarreau <w@1wt.eu> wrote:

> Hi Stephen,
>
> On Fri, Sep 20, 2013 at 11:50:27AM +0100, Stephen Farrell wrote:
> > > I find it better, but I'm still worried about promoting TLS to fix this
> > > with half a solution because we present TLS as a drop-in fix which is
> not
> > > true.
> >
> > That seems purely pejorative to me. In practice, TLS is the too
> > that's available here. Ignoring that because its imperfect would
> > be dumb.
>
> That's not my point, my point is that it's fairly possible to use TLS as
> badly as clear text, providing no security at all with the difference that
> you feel secure. And to me, feeling secure is much worse than not feeling
> secure.
>


-----

*NEWSWIRE:  Sept 20, 2013   HTTP/2.0 Team Officially Changes Charter.   New
goals include*
*making sure nobody feels secure.*

"We've known for some time that HTTP is an insecure protocol.  We thought
about improving security,
and we even have the technology to do it.  But we couldn't agree how to do
it.  So, we
decided that as long as nobody feels secure, we simply don't need to."
 said HTTP chair Mark
Nottingham.

HTTP, of course, is one of the core protocols of today's internet and has
never
been an encrypted protocol.  Recent news from the NSA shows that the US
government
joins the ranks of most other information-age governments with extensive
use of internet sniffing to track users around the globe.

"I thought the IETF was one organization which was helping protect the
internet," said an
Internet user.  "I guess I was wrong."

Other HTTP members, such as HTTP team member Roberto Peon, see this as
opportunity.
"We've been frustrated with our adversarial relationship with the NSA for
some time.  With
this new charter, we don't have to.  Our interests are now completely
aligned with the NSA.
We should all be afraid.  Isn't it great?"

So, while internet users everywhere will soon fear using their computers,
the HTTP team
is back on track to do absolutely nothing to secure its protocols this
year.  It's really not
a change, except now they're doing their job.

-------



Mike





>
> > > I think there is nothing wrong in saying that TLS completely addresses
> > > the issues only when reciprocal authentication is used (ie where the
> client
> > > can be trusted as well), and most of the issues (especially related to
> web
> > > browsing) when the server's authentication is enforced on the client.
> >
> > I have no idea what you mean. Are you saying that client-auth is
> > required in order to do better with privacy?
>
> Not privacy, but security in general. And in some cases it can even be
> about
> privacy. When my tax office requires my cert to log in, I'm more confident
> that I'm the only one to be able to consult my account than if it only
> requires my previous tax amount.
>
> > That'd seem like a load of nonsense, so I guess you're not saying that.
>
> For the general web I'm not saying that.
>
> > > Also
> > > we must not forget that this will probably be the last spec of
> HTTP/1.1 and
> > > that it will live forever. Who knows if TLS will still exist in 10
> years ?
> >
> > Now that's definite nonsense. The probability that HTTP (of any
> > version) will be protected only using technology that's not
> > genetically related to TLS in 2023 can only be reasonably
> > estimated at zero.
>
> Maybe in 2013 we'll be saying everywhere "please stop using TLS, it's
> totally
> dead and cracked, disable it by default from browsers" as we used to say
> about
> SSLv2 for a long time. Except that if a standard recommends a precise
> implementation, it creates confusion and discredits all the standard. I'd
> rather say "use encryption and authentication which at this time is
> provided
> by TLS when properly deployed" than "use TLS".
>
> > > We killed SSLv2 pretty quickly for example. That's why I'd rather talk
> about
> > > the principles than explicitly suggesting protocols that we might
> regret
> > > later (though they should be cited as examples).
> > >
> > > Passive interception on the web is just a detail IMHO.
> >
> > Recent events would seem to indicate otherwise unless you consider
> > all of Snowdonia to be a "detail".
>
> I don't know, I've never heard about "Snowdonia", all I can find is
> related to a city. However, my point remains that many times, passive
> interception already requires active interception (presenting yourself
> as the gateway), which is true in switched networks. Right now it's
> enough to just route the traffic, but it's not harder to proxy it
> when you can route it. And students with nothing to do on their holidays
> will quickly come with an easy to use tool. Look how Firesheep appeared!
> Who would have imagined that it was possible to sniff from a browser!
>
> > I would love to see this WG do a great job of helping folks to
> > deploy HTTP1.1 over TLS better.
>
> That's my goal as well, and I think that telling them that using TLS
> *correctly* is a solution is fine, but making them believe that "just
> switching to TLS" is the solution is worse than the current solution.
>
> > It should though at least
> > acknowledge the issues and the major countermeasure that does
> > get deployed and encourage that. And I think text along the
> > lines Mark initially suggested, or some of the reasonable
> > alternative suggestions, seems like the minimum that needs to
> > be done.
>
> Yes very likely, which is why I've been proposing some ideas which
> I know are not properly worded, but try to help spot the correct line
> between the two.
>
> Regards,
> Willy
>
>