Subject: Re: [TLS] fyi: (HTTP) Strict Transport Security and HASMAT (was: Eleven out of every ten SSL certs aren't valid)

From: Ivan Ristic <[email-masked]>
Date: Thu, 1 Jul 2010 08:51:35 +0100

On Thu, Jul 1, 2010 at 4:05 AM, =JeffH <[email-masked]> wrote:
> Hi,
>
> Ivan Ristic <[email-masked]> replied..
>>
>> On Tue, Jun 29, 2010 at 8:34 PM, Nicolas Williams
>> <[email-masked]> had written..
>>
>>> If you want to discuss how to improve the clients (e.g.,
>>> make it so there is no warning dialog, make it so you cannot connect to
>>> sites with bad certs period).
>>
>> I would like to see that very much (and have proposed it in the past).
>> Unfortunately, browser vendors will never do that for the fear of
>> losing customers.
>
> That's not exactly true at this time.

I was referring to my desire to have browsers reject all invalid
certificates by default. I am fine with having an option to turn that
behaviour in preferences, but I don't like the current implementations
that allow you to override it on site by site basis.

As for STS, I am familiar with it and my tool (and the survey) checks
for the presence of the STS response header.

> Strict Transport Security (STS (or HSTS as it might be re-acronymed))
> addresses a swath of these issues by facilitating a web site to declare to
> clients that it must be communicated with only over a secure transport i.e.
> TLS/SSL. There are of course a bunch of subtle aspects to this, so I won't
> address them here (pointer to I-D is below).
>
> Note that HSTS (nee STS) is presently implemented in Google Chrome 4.x, is
> coming in Firefox 4, is available as Force-TLS Firefox extension, as well as
> the HTTPS Everywhere FF extension, and is a feature of the NoScript FF
> extension. Also, www.PayPal.com presently sets this policy (we're actively
> encouraging others to do so too).
>
>
> Here is the present HSTS I-D..
>
>  HTTP Strict Transport Security
>  http://www.ietf.org/id/draft-hodges-strict-transport-sec-01.txt
>
> ..please discuss HSTS particulars on the HASMAT list..
>
>   [HASMAT]   "HASMAT -- HTTP Application Security Minus Authentication
>              and Transport",
>              <https://www.ietf.org/mailman/listinfo/hasmat>
>
>
> ..and please attend the BoF in Maastricht in a few weeks :)
>
>
> See also..
>
>  http://en.wikipedia.org/wiki/Strict_Transport_Security
>
>
> =JeffH
>
> PS: we're also encouraging all browser vendors to support HSTS.
>
> PPS: Chrome 4 also sports a "STS pre-loaded list"..
>
>  http://dev.chromium.org/sts
>
>
>
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls
>

-- 
Ivan Ristic
ModSecurity Handbook [http://www.modsecurityhandbook.com]
SSL Labs [https://www.ssllabs.com/ssldb/]

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Thu, 1 Jul 2010 10:12:51 +0200

> encouraging others to do so too).

I don't know whether security can be increased that way. The only rule
enforced is "pay to a CA or you are out of the web". An SSH-style
security approach might be more pragmatic

regards,
Nikos

---

From: Seth David Schoen <[email-masked]>
Date: Thu, 1 Jul 2010 01:51:10 -0700

=JeffH writes:

> Note that HSTS (nee STS) is presently implemented in Google Chrome
> 4.x, is coming in Firefox 4, is available as Force-TLS Firefox
> extension, as well as the HTTPS Everywhere FF extension, and is a
> feature of the NoScript FF extension. Also, www.PayPal.com presently
> sets this policy (we're actively encouraging others to do so too).

Currently HTTPS Everywhere implements a manual STS-like policy, i.e.,
someone tells us about a site that can use HTTPS and we eventually
get around to adding it to the list of rules.  In a real STS
implementation, of course, the browser would learn some of these
rules from machine-readable metadata, which we don't currently do.

Hopefully more widespread STS support in Firefox will soon allow
HTTPS Everywhere to focus on sites that need more complex rewriting
rules.

I see reason to think that some sites will continue to make HTTPS
available but not mandatory.  If so, many users will want to set
STS-preload-like policies for those sites in their own browsers,
which is something that both HTTPS Everywhere and NoScript can do.
I described the difference in the way that they do it at

http://archives.seul.org/or/talk/Jun-2010/msg00102.html

(tl;dr  NoScript lets you rewrite http:// to https:// for certain
domains, while HTTPS Everywhere lets you use arbitary regular
expression substitutions on URLs, which are necessary to make use
of certain sites' HTTPS support.)

---

From: Adam Langley <[email-masked]>
Date: Thu, 1 Jul 2010 08:12:55 -0400

> rules from machine-readable metadata, which we don't currently do.

Chrome also has an STS preloaded list, although it's not a roaring success:

AGL

---

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 01 Jul 2010 10:01:06 -0600

On 7/1/10 2:12 AM, Nikos Mavrogiannopoulos wrote:
> enforced is "pay to a CA or you are out of the web".

There are several CAs that provide no-cost certificates. The old line
about needing to pay to get on the secure web is obsolete.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Martin Rex <[email-masked]>
Date: Thu, 1 Jul 2010 20:13:10 +0200 (MEST)

> about needing to pay to get on the secure web is obsolete.

IPv4 address space is depleting and due to the lack of support for
TLS extension SNI (server name indication) in still >40% of the
internet user population, this rules out virtual hosting and you
will need to get a seperate IP-Address.  These requirements als
rule out the really affordable web-hosting services, so you'll
start at 10x the monthly fee if you want to offer a public
Webserver today compared to the basic service of a
virtually hosted Web-Server with your own domain name.

Which of the pre-trusted CAs in popular browsers issue free server certs?
Are there any pre-requisite/pre-conditions to qualify for free server certs?

-Martin

---

From: Adam Langley <[email-masked]>
Date: Thu, 1 Jul 2010 14:20:30 -0400

> Are there any pre-requisite/pre-conditions to qualify for free server certs?

I have successfully used http://www.startssl.com/, although without
extensive on older platforms.

AGL

---

From: Adam Langley <[email-masked]>
Date: Thu, 1 Jul 2010 14:36:58 -0400

> extensive on older platforms.

("testing" should have been included after "extensive")

AGL

---

From: Marsh Ray <[email-masked]>
Date: Thu, 01 Jul 2010 15:22:01 -0500

On 07/01/2010 01:13 PM, Martin Rex wrote:
> TLS extension SNI (server name indication) in still>40% of the

We do what we can, but it's not reasonable to expect grade-A security 
without incurring at least a little per-unit costs. If, in fact, one can 
serve globally trusted HTTPS site for only the cost of a CPU and a 
routable IP then I'd say the technology can be declared a success.

Contrast this with, say, classic FTP where the client also was assumed 
to have a routable IP.

Contrast this to the classic telephone system where you have to pay a 
monthly flat rate tax bill just to join the network. If you want to add 
end-to-end encryption it's probably going to have big up-front costs and 
won't even be that strong, if you're even permitted to own it. It's not 
likely to even be possible globally.

Don't get me wrong, I think the ideal cost for a minimal secure site 
should approach zero. In the case of a secure site, you want and need a 
trusted party that will do a good job verifying your claim to the 
identity (and conversely prevent others from falsely claiming the same). 
This requires a little bit of human effort to do properly.

What would folks have thought in 1995 if told that today the predominant 
cost of deploying an https site was just the use of the IP address?

I pay $20 per month for hosting and get that one IP along with plenty of 
CPU and net usage. Additional IPs are... $1 per month.

And yet, I still haven't set up SSL/TLS on that server. I admit it, I 
use SSH tunnels rather than TLS to encrypt my personal IMAP and SMTP 
connections. It's a little extra work to sign up for a proper cert and 
secure it all properly and my little blog doesn't seem worth it. That's 
probably where the real costs come from, security will always take just 
a little extra work.

- Marsh

---

From: Peter Gutmann <[email-masked]>
Date: Fri, 02 Jul 2010 15:29:10 +1200

Peter Saint-Andre <[email-masked]> writes:

>There are several CAs that provide no-cost certificates. The old line about
>needing to pay to get on the secure web is obsolete.

How many of those are (a) hardcoded into all the major browsers and (b) will
provide something other than short-term no-assurance certs?  What people are
paying CAs for is to turn off the browser warnings (thus the definition of a
certificate as "an X.509-formatted receipt for the bribe a web site owner pays
to a CA to turn off the browser warnings"), is there a free CA that offers the
same functionality, i.e. each cert issued turns off all the browser warnings
for the next year?

Peter.

---

From: Peter Saint-Andre <[email-masked]>
Date: Fri, 02 Jul 2010 09:28:54 -0600

> same functionality, i.e. each cert issued turns off all the browser warnings

I've been using certs from StartSSL for a few years now. Their roots are
in the cert bundles for Mozilla, OS X, Windows, etc. Their Class 1 certs
are free but their Class 2 certs require identity verification (for
which they charge something on the order of $40 for two years).
Naturally, YMMV, and there might be other CAs out there with a similar
model.

In any case, if you want to provide a semi-secure site on the Web then
you're going to need to pay for various parts of your system (hosting or
a physical machine that you host yourself with attendant needs for power
and so on, perhaps a bit of money for certificates, etc.). But that's no
different from any other service one might provide in life. TANSTAAFL.

Peter

--
Peter Saint-Andre
https://stpeter.im/