jsr340-experts@servlet-spec.java.net

[jsr340-experts] Re: [JIRA] (SERVLET_SPEC-95) Require that TLS is supported

From: Mark Thomas <markt_at_apache.org>
Date: Tue, 05 Aug 2014 21:43:09 +0100

On 24/07/2014 06:07, Greg Wilkins wrote:
>
>
>
> On 24 July 2014 07:10, Ed Burns (JIRA) <jira-no-reply_at_java.net
> <mailto:jira-no-reply_at_java.net>> wrote:
> Ed Burns created SERVLET_SPEC-95:
> ------------------------------
>
> ------
>
> Summary: Require that TLS is supported
>
>
>
> Ed et al,
>
> I'm very much against this. While I don't dispute the premise that
> "Pervasive Monitoring Is an Attack", I don't believe that https is a
> solution that comes anywhere near close enough to solve that issue.

While I agree that https is not sufficient to solve this problem I do
believe it is necessary. Therefore I support the requirement that
Servlet containers support TLS.

> https does not hide who you are talking to, when you talk to them or
> even how much you talk and in what size chunks. So pretty much all of
> your meta data is available to those monitoring you. By examining
> public websites you visit, the monitor can use size and sequence
> information to work out what pages you have visited.

While an awful lot can be inferred / guessed from meta data, that isn't
the same as knowing exactly what the content is. Therefore I am of the
view that the content is worthy of protection.

I'm not saying more couldn't/shouldn't be done to protect the meta data
(as well as more being done to make folks aware of what their meta data
might give away) but even with current meta data there is benefit in
protecting the content.

> Worse yet, because
> of things like http://en.wikipedia.org/wiki/CRIME it is often possible
> for even the content to be cracked. CRIME came about because
> compressed data that had never been considered for security was put over
> TLS.

Despite the noise that was made about CRIME and then BREACH I haven't
yet seen any examples of a practical attack for either of those
exploits. To be fair to the original reporters of CRIME they were quite
clear about the (low) possibility of using it for a practical attack -
the noise came from other quarters. That isn't to say we should be
complacent but neither is the sky falling in.

> TLS is simply insufficient to provide any level of protection from
> monitoring and it actually makes things worse to pretend that it does.

I strongly disagree with that statement. It is my view that the use of
TLS does provide some protection against eavesdropping and that the
protection provided is worth the associated costs.

I do agree that TLS alone is not sufficient. Total protection from
monitoring would require some major protocol changes (unlikely) and is
still unlikely to be successful against a nation state with the ability
to monitor large proportions of the internet. What we can do is take
steps in the right direction to improve privacy where we can and
requiring support for TLS is a reasonable step.

> Traffic carried by TLS needs to be carefully considered so that it is
> protected from CRIME like attacks. The more data sent over TLS that an
> attacker can control makes CRIME-like vulnerabilities worse, so forcing
> non secure traffic to TLS will reduce the protection available to
> important data.

I don't see a downside to requiring that Servlet containers support TLS
if an application requests it.

If all web traffic on the internet was over https rather http then I
can't see how that could make life easier for an eavesdropper but I can
see how it would make it harder. On balance, I think there is benefit in
using https everywhere but I can see how others may reach a different
conclusion even though I don't agree with it.

Mark