Subject: [TLS] Eleven out of every ten SSL certs aren't valid

From: Peter Gutmann <[email-masked]>
Date: Tue, 29 Jun 2010 19:50:38 +1200

In case someone here still hasn't seen this, the subject is a reference to:

  SSL Certificates In Use Today Aren't All Valid
  http://www.esecurityplanet.com/features/article.php/3890171/SSL-Certificates-In-Use-Today-Arent-All-Valid.htm

which posits that only 3% of SSL certs in use today are valid.  The figures
seem a bit suspicious though, for example they claim 23 million SSL sites
while the same article quotes Netcraft as claiming there are 1.5 million SSL
certs in use (the Netcraft figures may be for CA-issued certs only, since they
quote Verisign as a percentage of that total).  Still, 3% seems pretty low,
could this be due to something like virtual hosting and the client not sending
the hostname, thereby getting the wrong cert?  Even with that though, I 
wouldn't have expected a 97% invalidity rate.

Peter.

---

From: Ivan Ristic <[email-masked]>
Date: Tue, 29 Jun 2010 14:31:36 +0100

The numbers in the article come from the preview of my research, which
I presented in a webcast last Thursday. Here's the summary of the
presentation:

1. I started with 119M domain names (out of 193M registered
worldwide). The 119M include all .com, .org, .net, .info, .biz, and
.us domain names.
2. 92M domains are active on port 80 or port 443
3. 33M domains have port 443 open
4. 22.65M domain names run SSL on port 443
5. On 0.72M domain names certificates match the domain name.

I am now focusing on the 720K certificates that are potentially valid.

Once I find out exactly how many of those certificates are valid, I
will make two claims:

- X% of web servers properly run SSL (where X will be < 3%)
- Y% of certificates are valid (where Y will be significantly higher than > 3%)

I should be able to post my presentation online tomorrow, after which
I will follow-up here.

BTW, my assessment methodology is available on
https://www.ssllabs.com, along with an online assessment tool (that
works with a single hostname). There's additional material on the SSL
Labs mailing list. I will publish the complete report in about a
month.

I welcome all feedback, as well as deeper involvement if you're
interested in the topic.

Cheers,
Ivan

On Tue, Jun 29, 2010 at 8:50 AM, Peter Gutmann
<[email-masked]> wrote:
> _______________________________________________
> 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: Ivan Ristic <[email-masked]>
Date: Tue, 29 Jun 2010 14:49:31 +0100

I forgot to mention another thing: when I looked at the Alexa's top 1M
sites, 27.86% of all certificates matched the domain name.

---

From: Martin Rex <[email-masked]>
Date: Tue, 29 Jun 2010 15:50:22 +0200 (MEST)

>From the quoted article:

"Only about 3.17 percent of the domain names matched," Ristic said.
(Ivan Ristic, director of engineering at Qualys)
is probably about the scan engine to which an URL was posted to the
TLS mailing list a short while ago:

https://www.ssllabs.com/ssldb/index.html

This is based on the seriously flawed assumption that a DNS entry that
can be resolved into an IP-Address of a machine with a Web-Server on
Port 80 will have the same Web-Server on Port 443 if port 443 is active.

Try "www.oracle.com", "www.googlemail.com", "www.gmx.de".
You can get correct answers for "mail.google.com" and "www.gmx.net".

What is really irritating is that a service like "www.hotmail.com"
is not accessible via TLS _at_all_ and suggests you to enter 
username an password into a plain http form -- OUCH!

-Martin

---

From: Adam Langley <[email-masked]>
Date: Tue, 29 Jun 2010 10:11:51 -0400

> You can get correct answers for "mail.google.com" and "www.gmx.net".

You should get a correct certificate for www.googlemail.com if you
present a Server Name Indication extension.

AGL

---

From: Ivan Ristic <[email-masked]>
Date: Tue, 29 Jun 2010 15:15:39 +0100

> Port 80 will have the same Web-Server on Port 443 if port 443 is active.

If you're referring to my work, I didn't make any assumptions. I
merely reported the findings, which are that  about 3.17% of domain
names that respond with SSL on port 443 have a potentially valid
certificate.

If you're wondering, the results are without SNI. I will have another
run later with SNI enabled.

---

From: Tim Dierks <[email-masked]>
Date: Tue, 29 Jun 2010 10:36:56 -0400

> names that respond with SSL on port 443 have a potentially valid

In my opinion, this is a pretty meaningless statistic. There's no warranty
that just because a domain name maps to an IP address and that IP address
has an SSL server that the SSL server will respond with a certificate that
matches the domain name in question. If I go and register a thousand domain
names and give each one a CNAME that points to www.modsecurity.org, and you
go and find it serves SSL on 443, but doesn't present the certificates for
my domains, so this percentage goes down, what does that mean? Nothing at
all.

If you had a statistic about what fraction of https:// links on the Internet
point to misconfigured servers, that would be more interesting.

 - Tim

---

From: Martin Rex <[email-masked]>
Date: Tue, 29 Jun 2010 16:38:16 +0200 (MEST)

Ivan Ristic wrote:
> Martin Rex wrote:

That is going to make it only marginally better.

Since MSIE browsers on Windows XP (which is still at 50% of the market)
do not support SNI, the sites that require SNI to work will be rare.

Virtual hosting, on the other hand, is pretty common.  And buying
similar domain names and setting up HTTP-redirects is also pretty
common.

It is simply impossible to come up with meaningful numbers if
you starting point is DNS-records and accessible hosts.

-Martin

---

From: "Blumenthal, Uri - 0668 - MITLL" <[email-masked]>
Date: Tue, 29 Jun 2010 10:48:24 -0400

On 6/29/10 10:36 , "Tim Dierks" <[email-masked]> wrote:
>> If you're referring to my work, I didn't make any assumptions.
>> I merely reported the findings, which are that  about 3.17% of domain
> In my opinion, this is a pretty meaningless statistic.

I concur.
--
Regards,
Uri         [email-masked]
<Disclaimer>

---

From: Rob P Williams <[email-masked]>
Date: Tue, 29 Jun 2010 11:03:22 -0400

Two comments, one on protocol, one on research...

Protcol:
========

RFC 3546 (3.1):
   If the server understood the client hello extension but does not
   recognize the server name, it SHOULD send an "unrecognized_name"
   alert (which MAY be fatal).

Asking www.goolemail.com for www.oracle.com proceeds with mail.google.com's certificate...

Martin's example of www.gmex.net sends a html forward to www.gmex.de using www.gmex.de's certificate...

SNI has the mechanism to say:
	Not me!   - which Google Mail isn't using...

SNI should have the mechanism to do what GMEX is doing - but doesn't.
	Client Hello: Give me www.gmex.de
	Server Hello: Let's use RSA!, ps: but you should try www.gmex.net 

Browsers could then make a more informed choice then just a "this site is bad" page.

Let's draft SNI(II)!!!

Research:
=========

What steps are being taken to verify that 'valid' ssl is even intended?

The www.oracle.com example is perfect. Oracle doesn't have an SSL site so you get an Akamai certificate - and your browser says, "This is not trusted" - which is correct!

I wonder how different your numbers are when the IP address is reversed and compared again to the certificate. That's one way to measure lack of intent to have an SSL site.

Test servers that we host have self signed certificates with various key sizes and curves... We do not intend for them to be trusted. A regular user who has no interest in TLS interop getting a non-trusted warning from these test servers is a good thing. All the test sites out there are skewing your numbers.

It appears like the people at www.gmex.de intend for people to access them as www.gmex.net - that's why they bought the www.gmex.net certificate...

If you are trying to prove that lots of people don't intend to have SSL on their website, or have it accessed the way your tried - then you could well be on the road to achieving that goal.

These sound like numbers intended to scare people. If you are going to publish without the first paragraph mentioning that "100% of modern browsers will alert a user to configuration issues that are detected herein" - then... what's your point?

--
rob | Team Lead, Certicom Java Toolkits
Certicom Corp. | A subsidiary of Research In Motion Limited

[email-masked]
www.certicom.com

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Adam Langley
Sent: Tuesday, June 29, 2010 10:12 AM
To: [email-masked]
Cc: [email-masked]
Subject: Re: [TLS] Eleven out of every ten SSL certs aren't valid

AGL

---------------------------------------------------------------------
This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.

---

From: Ivan Ristic <[email-masked]>
Date: Tue, 29 Jun 2010 16:19:24 +0100

> my domains, so this percentage goes down, what does that mean? Nothing at

Certainly, the measurement is imperfect. I find it useful, even if you don't.

> point to misconfigured servers, that would be more interesting.

I am pursuing that option as a separate effort. It involves convincing
other organizations to share their data and I am not sure how that
will go.

In the meantime, I think looking at the Alexa's top 1M domain names is
the next best thing.

---

From: Ivan Ristic <[email-masked]>
Date: Tue, 29 Jun 2010 16:39:04 +0100

On Tue, Jun 29, 2010 at 4:03 PM, Rob P Williams <[email-masked]> wrote:
> ...

I have collected about 720K certificates that match the domain names
from which they were served. I think it's fair to say those are the
cases where SSL was intended.

Obtaining those certificates was the goal of the first phase of my
survey. All these other numbers are just a byproduct of that.

> These sound like numbers intended to scare people. If you are going to publish without the first paragraph mentioning that "100% of modern browsers will alert a user to configuration issues that ar…

The numbers are real, and if they scare some people so be it. My point
is to look at how SSL is used in real world and report it. I am in the
middle of my research and I don't know yet what I will find, but for
me the value is in knowing, irrespective of the results.

---

From: Joshua Davies <[email-masked]>
Date: Tue, 29 Jun 2010 10:43:18 -0500

Well, ok, but... why listen on port 443 if you don't plan to support SSL 
in the first place?  I doubt that oracle.com is being run from a 
shared-hosting site.  Most likely it's Akamai that's doing something 
that doesn't mix well with TLS; Oracle may not care, but this, I would 
think, would be of some interest to the IETF TLS working group...

> The www.oracle.com example is perfect. Oracle doesn't have an SSL site so you get an Akamai certificate - and your browser says, "This is not trusted" - which is correct!

<http://twiki.dev.sabre.com/twiki/bin/view/Travelocity/TVLYArchitecture>

---

From: Yoav Nir <[email-masked]>
Date: Tue, 29 Jun 2010 18:51:47 +0300

No idea about Oracle, but port 443 is one of those ports that are open on most firewalls, so it "just works".

In some ways port 443 is even better than port 80, because some firewalls try to inspect port 80, but allow port 443 traffic as-is because it's inspected.

I know of one implementation at least that runs IKE over port 443.

Of course, modern firewalls can inspect port 443 for property formatted SSL/TLS records, but most of them don't do it.

Yoav
(who works for a firewall vendor)
________________________________________
From: [email-masked] [[email-masked]] On Behalf Of Joshua Davies [[email-masked]]
Sent: Tuesday, June 29, 2010 18:43
To: [email-masked]
Subject: Re: [TLS] Eleven out of every ten SSL certs aren't valid

Well, ok, but... why listen on port 443 if you don't plan to support SSL in the first place?

---

From: Rob P Williams <[email-masked]>
Date: Tue, 29 Jun 2010 12:18:09 -0400

Hi Ivan,

Good luck with your research.

Security needs continuous audits - Thank you for your efforts.

[email-masked]
www.certicom.com

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Tue, 29 Jun 2010 18:20:38 +0200

> cases where SSL was intended.

Out of curiosity, how do you define matching. Do you use the CN only or
 subject alternative names as well?

---

From: Bill Daskaluk <[email-masked]>
Date: Tue, 29 Jun 2010 12:23:33 -0400

> "Only about 3.17 percent of the domain names matched," Ristic said. "So we
> have about 22 million SSL servers with certificates that are completely
> invalid because they do not match the domain name on which they reside." 

Is a certificate 'completely invalid' because it does not match the domain?
If a valid certificate is issued to X, and a client connects to what it thinks
is Y and receives a certificate belonging to X, this does not make the
certificate completely invalid -- especially when X and Y share the same
server IP and the client is connecting to the IP, not the domain.

> - Y% of certificates are valid (where Y will be significantly higher 

This conclusion sounds more reasonable as long as "web server" is carefully defined.

Regards,
Bill Daskaluk

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Ivan Ristic
Sent: Tuesday, June 29, 2010 9:32 AM
To: Peter Gutmann
Cc: [email-masked]
Subject: Re: [TLS] Eleven out of every ten SSL certs aren't valid

Cheers,
Ivan

---

From: Tim Dierks <[email-masked]>
Date: Tue, 29 Jun 2010 12:23:42 -0400

> Certainly, the measurement is imperfect. I find it useful, even if you

What is it useful for? What behavior or process is more or less secure in
some correlation with this value? If it went from 3% to some other number
(either up or down), what would that imply?

Best wishes,
 - Tim

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 29 Jun 2010 11:33:55 -0500

> wouldn't have expected a 97% invalidity rate.

The subject line is very funny, but, seriously, this doesn't bother me
in the least.  Why?  Because anyone can put up a site with an invalid,
self-signed, or might-as-well-be-self-signed-because-no-one-uses-its-
root-CA cert.  Therefore the number of sites with such certs is utterly
and completely _meaningless_ [m_e_a_n_i_n_g_l_e_s_s_].

What matters is that the sites that ought to be using HTTPS with valid
certs are[*].  I'm talking about banks, payment sites, shopping sites
that accept credit cards, etcetera.  By and large those appear to be
valid most if not all the time I, as a user, need them to be.  I'd like
to see a study of such sites' TLS and PKIX usage.

So I'd phrase this as 9-out-of-10 sites that need to have valid certs.

Nico

[*]  Ignoring, for lack of a better alternative, the fact that browsers
     ship with such long lists of trust anchors that we might as well
     not even try to pretend we're using a PKI.
--

---

From: Ivan Ristic <[email-masked]>
Date: Tue, 29 Jun 2010 19:25:39 +0100

The lot: the common name, wildcards, and alternative names too.

---

From: Ivan Ristic <[email-masked]>
Date: Tue, 29 Jun 2010 19:29:45 +0100

On Tue, Jun 29, 2010 at 5:33 PM, Nicolas Williams
<[email-masked]> wrote:
> and completely _meaningless_ [m _e _a _n _i _n _g _l _e _s _s _].
>

The problem with that view is that, while the users are experiencing
all those sites with invalid certificates they are getting used to the
idea that nothing bad comes from browser warnings. Then, one day, when
they're accessing their bank's web site from an insecure network, they
ignore the one warning they shouldn't and get owned by the MITM guy.

---

From: Marsh Ray <[email-masked]>
Date: Tue, 29 Jun 2010 14:13:13 -0500

First of all, count me as one who thinks Ivan's work is really cool.

On 06/29/2010 01:29 PM, Ivan Ristic wrote:
> idea that nothing bad comes from browser warnings.

But we don't know that, do we?

I mean, I can set up a web hosting server with an HTTPS-based "webmin" 
(or whatever admin page I might want to use). I could protect that admin 
login using a cert issued by my own private CA. I could then v-host 1000 
non-SSL web sites, still using only a single shared IP address.

Doesn't your methodology count this case as "1001 invalid certs" where, 
in reality, everything that is supposed to work is configured correctly?

- Marsh

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 29 Jun 2010 14:34:17 -0500

> ignore the one warning they shouldn't and get owned by the MITM guy.

You seem to be confused as to what I actually wrote.

There is no such "problem with [my] view" because you cannot stop people
from deploying servers with bad certs.  It's a _fact of life_.  Or
perhaps it needn't be if, say, it were illegal to have sites with bad
certs (is that what you're proposing??).

Now, what our client applications do about such servers _is_ a problem.
If that was your point, well, we agree, and there's no need to put words
in my mouth.  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).

Nico
--

---

From: Ivan Ristic <[email-masked]>
Date: Tue, 29 Jun 2010 21:22:50 +0100

> But we don't know that, do we?

Of course we do, from anecdotal evidence. The worst offenders are on
intranets/private hosts everywhere.

> I mean, I can set up a web hosting server with an HTTPS-based "webmin" (or
> whatever admin page I might want to use). I could protect that admin login
> using a cert issued by my own private CA. I could then v-host 1000 non-SSL
> web sites, still using only a single shared IP address.
>
> Doesn't your methodology count this case as "1001 invalid certs" where, in
> reality, everything that is supposed to work is configured correctly?

I disagree that your described setup is working correctly. In my view,
if you delegate a domain name to a server, you should either respond
properly (with the same site) on both 80 and 443, or shut down port
443 if you don't need/want SSL.

---

From: Ivan Ristic <[email-masked]>
Date: Tue, 29 Jun 2010 21:29:01 +0100

> You seem to be confused as to what I actually wrote.

No, not at all. I was responding to this sentence in particular:

"What matters is that the sites that ought to be using HTTPS with
valid certs are"

> from deploying servers with bad certs.  It's a _fact of life_.

The fact that we cannot stop bad certs is not relevant. Such sites are
still reducing the effectiveness of SSL, even for the "sites that
ought to be using HTTPS". And that was my point.

> 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.

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 29 Jun 2010 15:35:46 -0500

> 443 if you don't need/want SSL.

Do you consider an otherwise valid (unexpired, ...) self-signed cert to
be valid?  What if it's not pre-shared to you?

Do you consider an otherwise valid cert to be invalid if you have no
validation path for it to a CA you trust?  What if someone else can find
a validation path for it to a CA _they_ trust?

Surely it would be fine to have servers that by default generate
self-signed certs and use those for HTTPS.  Or do you disagree?  Do you
reject the use of pre-sharing of certs?  Do you demand that we all use
actual PKIs?

Nico
--

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 29 Jun 2010 15:46:15 -0500

> "What matters is that the sites that ought to be using HTTPS with

[To be clear, that was followed with a sentence-ending period.]

The context was just how awful it is that 97% of servers don't have
valid certs.  There's clearly NOTHING we can do to prevent that short of
pushing for legislation (treaties?) making the act of running such
servers illegal.  If there's no much you can do about a problem, then
you focus on other things.  My immediate focus switched to whether the
servers that _matter_ have valid certs.  Was that wrong?  Yes, we can
also focus on client behavior as well, but things are not as simple as
you might think (see below).

> ought to be using HTTPS". And that was my point.

Maybe, but if there's nothing you can do about this, what do you propose
to do then?

> I would like to see that very much (and have proposed it in the past).

OK, now we're getting somewhere.

Of course, it happens that cert pre-sharing, and SSH-style leap-of-faith
are very convenient for users who either don't want to deploy a PKI or
don't want to pay to participate in someone else's PKI.  Breaking this
will only lead to much complaining, and will risk our credibility with
users who don't have PKIs (or other authentication infrastructure).

> Unfortunately, browser vendors will never do that for the fear of

And that's because there are issues that you're not considering (see
above) or not considering important, but which many of us do.

Nico
--

---

From: Tim Dierks <[email-masked]>
Date: Tue, 29 Jun 2010 17:10:30 -0400

On Tue, Jun 29, 2010 at 4:46 PM, Nicolas Williams <
[email-masked]> wrote:

> valid certs

That is not what is being said. What is being said is that 97% of DNS names
that point at SSL servers do not validate with those DNS names. This is, on
its face, is a statement about DNS configuration, not about SSL servers.
(Creating a thousand DNS names for the IP address of a single SSL server
will change this stat, although the owner and operator of the SSL server
need not be involved in any way.)

To learn anything interesting about SSL servers at all, more work must be
done.

 - Tim

---

From: Ivan Ristic <[email-masked]>
Date: Tue, 29 Jun 2010 22:18:06 +0100

Nico, forgive me for not answering your questions, but I don't have
enough time to give them justice.

In brief, I am not demanding nor proposing anything. I am just
measuring. If you can think of a better way to measure things, I will
be all ears.

---

From: Tim Dierks <[email-masked]>
Date: Tue, 29 Jun 2010 17:21:53 -0400

> measuring. If you can think of a better way to measure things, I will

I would suggest you crawl the web for invalid links (https links that point
to servers with invalid certificates), or find SSL servers which are not
available at the DNS servers named in their certificates.

 - Tim

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 29 Jun 2010 16:24:11 -0500

> its face, is a statement about DNS configuration, not about SSL servers.

Ah, pardon my evidently too-cursory read.  I'd like to see a breakdown
by HTTP/1.0 versus HTTP/1.1 then (since the latter supports
virtualization while the former does not).

> need not be involved in any way.)

Right.  One might want to consider only all the names for any one server
that come from the same zone file as the server's addresses' canonical
domainnames.

> To learn anything interesting about SSL servers at all, more work must be

In particular it's important to distinguish sites that serve HTTPS just
because from sites that serve HTTPS because they really ought to, and
from sites that serve HTTPS as part of being attack sites.

If it turns out that 97% of sites that accept credit card payments have
invalid certs (in some way or another), then we'd definitely have a
problem.  I suspect that's not the case though.

Nico
--

---

From: Ivan Ristic <[email-masked]>
Date: Tue, 29 Jun 2010 22:15:50 +0100

On Tue, Jun 29, 2010 at 10:10 PM, Tim Dierks <[email-masked]> wrote:
> On Tue, Jun 29, 2010 at 4:46 PM, Nicolas Williams

Yes, of course. I am attaching some of the metrics I will be
collecting from the 720K domains that have potentially valid
certificates. That's the meat of my survey.

It's too late to change the metrics now (I've started with the
collection), but the plan is to continue with the survey indefinitely.

---

From: Marsh Ray <[email-masked]>
Date: Tue, 29 Jun 2010 16:40:17 -0500

On 06/29/2010 03:22 PM, Ivan Ristic wrote:
> On Tue, Jun 29, 2010 at 8:13 PM, Marsh Ray<[email-masked]>  wrote:

I may agree with you because there seems to be convincing evidence of 
that in aggregate, but that doesn't make us correct in any specific 
cases to say "this dns name resolving to an IP that listens on TCP port 
443 and presents a cert that we don't trust is 'bad' and thus an 
'offender'".

If https://employee-portal.example-bank.com/ has a cert issued by a 
trusted root calling itself "internal-ca.example-bank.com" I would be 
foolish to trust it at face value. However, that does not mean I can say 
that no one is correct in trusting it or that it in inherently "invalid".

> 443 if you don't need/want SSL.

I but I do want SSL in this scenario. I just can't vhost it the way I 
can non-ssl sites.

By this methodology, I can host 1000 http sites on a single IP address 
at TCP port 80, but as soon as that IP address accepts a connection on 
TCP port 443 it immediately counts as 1000 invalid certs.

I liked the suggestion about looking for https: links on the net. Scores 
could even be weighted by incoming links, a' la pagerank. If a dns name 
really has zero links to it, it's questionable whether or not its really 
relevant as a part of the web.

If your conclusion is that "97% of sites are invalid", that doesn't fit 
with my experience as a web user. But I think of a "secure SSL site" as 
those that are actively maintained and that I would visit with some 
expectation of working security. I suppose there are a nearly-unlimited 
number of sites with test and expired certs (and it seems you've gone 
out of your way to dig them up) so it doesn't seem useful to count them 
in the same bucket at the sites people do care about.

On the other hand, if your conclusion is "the vast majority of domain 
names are hosting content no one cares about enough to secure" then I 
don't think this is news to anyone!

There's something really useful in this data if we could just figure out 
the right question to ask. 42 and all that.

- Marsh

---

From: Ivan Ristic <[email-masked]>
Date: Tue, 29 Jun 2010 22:44:04 +0100

> relevant as a part of the web.

Isn't that exactly what we'd be getting from looking at the most
popular 1 million domain names?

> On the other hand, if your conclusion is [...]

Well, that's the thing. I didn't make any conclusions, but there are
several people on this list who assumed I did.

---

From: Marsh Ray <[email-masked]>
Date: Tue, 29 Jun 2010 17:21:02 -0500

On 06/29/2010 04:44 PM, Ivan Ristic wrote:
> On Tue, Jun 29, 2010 at 10:40 PM, Marsh Ray<[email-masked]>
> wrote:
>>
>> ...
>>
>> I liked the suggestion about looking for https: links on the net.
>> Scores could even be weighted by incoming links, a' la pagerank. If
>> a dns name really has zero links to it, it's questionable whether
>> or not its really relevant as a part of the web.
>

Perhaps, but I would want a precise definition of "most popular" before 
agreeing to the "exactly". :-)

> several people on this list who assumed I did.

You've done something cool and ambitious and given some numbers to the 
press. It's fair to expect people to look at it very closely for stated 
and implied interpretations. (This is partly why it's rare to see 
researchers publish raw data with no analysis.)

Not to mention that the numbers by themselves raise some good questions 
for the SSL/TLS community. People want to discuss it with you.

 From TFA:
> "So we have about 22 million SSL servers with certificates that are
> completely invalid because they do not match the domain name on which
> they reside."

This is where I think there's some room for legitimate discussion about 
the numbers as presented.

Is it correct to count a server reached from a misdirected DNS entry as 
"completely invalid" SSL?

According to the RFCs as I understand them, we can only say (an 
otherwise well-formed) cert is invalid in the context of a protocol, an 
requested identity, a set of trusted root certs, a time of validation, 
etc. We all know there's a good deal of variation in clients' trusted 
roots. Revocation data could be another interesting contextual variable.

- Marsh

---

From: Bruno Harbulot <[email-masked]>
Date: Wed, 30 Jun 2010 01:01:12 +0100

Hi,

On 29/06/2010 22:15, Ivan Ristic wrote:
> On Tue, Jun 29, 2010 at 10:10 PM, Tim Dierks<[email-masked]>  wrote:

Not even that, it's a flaw in the assumption that for each DNS name 
there will be an HTTPS server listing there. That's definitely not true.

> collection), but the plan is to continue with the survey indefinitely.

I suppose it depends on what you've collected, in particular whether 
you've kept some of the raw data before giving a "red F" with score 0 to 
a certificate.

I think https://www.ssllabs.com/ssldb/ is a fairly neat tool. I've 
scanned a couple of machines I'm hosting, and it diagnosed a weak cipher 
suite on one of them, which I was able to correct. Thanks for that!

However, I think there are two major problems with the study:
   - the fact it seems to propagate the myth that a cert from a big CA 
is necessarily a "safe" cert and vice versa.
   - the fact that it assumes that a domain name will have one IP 
address on its own or that servers all support SNI.

1. Non-major CAs -> score 0, regardless of the other indicators.

We tend to rely on the UK e-Science CA [1] for a number of machines. 
Some of my machines with UK e-Science certs score like this:
  - Certificate: 0 (unknown CA)
  - Protocol Support: 85
  - Key Exchange: 90
  - Cipher Suites: 90

That would get a "green A" if the CA was recognised. Unfortunately, it's 
not known by the tool, so it's disqualified. That's a bit harsh, isn't it?

To give you a bit of background, to get a certificate (server or client) 
with this CA, I've had to turn up in person to see one of the CA 
representatives and show an official photo ID. How many CAs that are 
trusted out of the box in major browsers require that?
... And for all that trouble, I only get a blue bar in my browser (when 
I've imported the CA cert, of course). Surely, that would be worth a 
green bar!

I would expect a bit more care in the wording (especially with quite a 
graphic colour ranking) when it comes to these issues. The accompanying 
document explains a bit the problem, but probably not well enough. 
Non-experts, including journalists after some sensational piece of news 
would quite easily focus on the "big red F" on that webpage, not 
necessarily understanding that it's in fact meaningless out of context.

Admittedly, I have much less experience than many other people on this 
list, but I still hope TLS experts understand that Big CAs and EV 
certificates are not the perfect solution for trust management. (There 
probably isn't one anyway.)

2. Host names.

There are a number of shared web hosting providers that have a large 
number of host names hosted on the same IP address. (Typically, with 
VirtualHosts on Apache Httpd). Sometimes, these servers will also have 
something listening on port 443 for a specific host name (perhaps a 
common admin interface or something like that, maybe not even intended 
to be used by the admin in which case a self-signed certificate would be 
just fine.)
I suspect that many domains never really intended to host content over 
HTTPS there.
Drawing the conclusion that there ought to be an HTTPS server with a 
certificate with the host name that the tool is after (as opposed to the 
host name the user would have used) is quite a short-cut.

This could be solved with SNI, but considering that SNI was only 
introduced in Apache Httpd (mainstream) in May 2009 [2], it's not really 
surprising that it's not widely deployed in production systems yet.

The point is that, before testing whether a certificate is valid, you 
should check whether there is a validity test to be made, in particular 
whether someone said there would be an HTTPS server there.
 From what I understand, the collection of names was more or less made 
from the whois registry. Have you found an https URI for each an 
everyone of them? Did you add the "www" prefix by default? If no one has 
claimed there would be a "secure website" at that domain, why would you 
test that non-existent claim?

The tool is a good idea, however, the conclusions are flawed (and the 
esecurityplanet.com article focusses on the bits that are wrong.)

Best wishes,

Bruno.

[1] http://www.ngs.ac.uk/cacerts
[2] http://svn.apache.org/viewvc?revision=776281&view=revision

---

From: Bill Frantz <[email-masked]>
Date: Tue, 29 Jun 2010 17:23:24 -0700

>survey. All these other numbers are just a byproduct of that.

I would be interesting to see which trust roots configured in 
current browsers are in actual use in the wild. Your collection 
of certificates could help answer this question, and perhaps 
help remove cruft from browser distributions.

Cheers - Bill

-----------------------------------------------------------------------
Bill Frantz        | OAuth -  It's the best that  | Periwinkle
(408)356-8506      | the wrong way of doing things| 16345 
Englewood Ave
www.pwpconsult.com | can provide. - Mike Stay     | Los Gatos, 
CA 95032

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 29 Jun 2010 19:29:22 -0500

On Tue, Jun 29, 2010 at 05:23:24PM -0700, Bill Frantz wrote:
> current browsers are in actual use in the wild. Your collection of
> certificates could help answer this question, and perhaps help
> remove cruft from browser distributions.

Excellent idea!

Nico
--

---

From: Ivan Ristic <[email-masked]>
Date: Wed, 30 Jun 2010 06:47:33 +0100

> agreeing to the "exactly". :-)

My understanding is that Alexa (http://www.alexa.com) uses the toolbar
to record where people go on the Internet. They then use that data to
maintain the list of most popular web sites.

In the light of yesterdays bashing on the metrics, I am starting to
like Alexa's list more and more, because it's not only much easier to
monitor (1M sites and about 110K certificates with matching names),
but makes more sense.

> This is where I think there's some room for legitimate discussion about the
> numbers as presented.
>

The way I see it, it's a fact. There is no way for someone to know if
a domain name wants SSL. (It's a separate topic, but I think there
should be. Just as there should be a way for a domain name to say it
wants _only_ SSL.)

I make not claim that all those domain names "intended" to run SSL,
but in fact they do. People focus on the negatives, because they make
nice headlines, but I want to know how many domain names _do_ run SSL
properly.

> According to the RFCs as I understand them, we can only say (an otherwise
> well-formed) cert is invalid in the context of a protocol, an requested
> identity, a set of trusted root certs, a time of validation, etc. We all
> know there's a good deal of variation in clients' trusted roots. Revocation
> data could be another interesting contextual variable.
>
> - Marsh

---

From: Ivan Ristic <[email-masked]>
Date: Wed, 30 Jun 2010 07:05:00 +0100

On Wed, Jun 30, 2010 at 1:01 AM, Bruno Harbulot
<[email-masked]> wrote:
> Not even that, it's a flaw in the assumption that for each DNS name there
> will be an HTTPS server listing there. That's definitely not true.

It's the assumption accusation again. It is not an assumption. It is
test to see how many domain names have port 443/SSL/valid certificate
configured. Although you claim otherwise, there are many domain names
who respond with SSL on port 443 and have invalid certificates. Now,
we can argue what that means, and, granted, it does not mean much.
What is meaningful, is that there is an X number of domain names that
_does_ have SSL configured properly.

>  - the fact it seems to propagate the myth that a cert from a big CA is
> necessarily a "safe" cert and vice versa.

I don't like the many CAs as much as the next guy, but for the
"normal" person on the Internet today, that's the only thing to rely
on. It may be flawed, but it's less flawed than self-signed
certificates (which a normal person has a 0% chance of understanding).

> We tend to rely on the UK e-Science CA [1] for a number of machines. Some of
> my machines with UK e-Science certs score like this:
> That would get a "green A" if the CA was recognised. Unfortunately, it's not
> known by the tool, so it's disqualified. That's a bit harsh, isn't it?

It may be, but I get a certificate warning when I go to
https://www.ngs.ac.uk/. It's the same thing.

The tool is designed from a perspective of an average Firefox user.
It's an SSL client implementation, just like any other browser/client.

I'd love to support multiple trust bases (as well as custom trust
stores), but the maintenance of multiple trust stores is too much work
for me to handle right now.

---

From: Bruno Harbulot <[email-masked]>
Date: Wed, 30 Jun 2010 08:35:05 +0100

Hi,

On 30/06/2010 07:05, Ivan Ristic wrote:

> test to see how many domain names have port 443/SSL/valid
> certificate configured. Although you claim otherwise, there are many
> domain names who respond with SSL on port 443 and have invalid
> certificates. Now, we can argue what that means, and, granted, it
> does not mean much. What is meaningful, is that there is an X number
> of domain names that _does_ have SSL configured properly.

Sure, but that's exactly the problem, the assumption that they should
have a valid cert there. It's more than that, it the assumption that
there would be a web server at all behind a domain name (admittedly,
that's very likely to be the case but the internet and the web are not
quite the same thing.)

You seem to have missed a fundamental point of the architecture of the
WWW: the fact that you're meant to navigate it through linking, not by 
guessing from a domain name.

Of course, guessing the website from the domain name is likely to give 
some good results. There are a few assumptions on the way there.

You're making the assumption that for "example.com" there will be a
"http://www.example.com/". It's a good assumption, but it's still an
assumption. Who said there should be an HTTP server listing? Next
assumption is that there will be a 'www' prefix.

The PDF <https://www.ssllabs.com/projects/rating-guide/index.html> says:
> Make sure the certificate is valid for all the domain names that will
> be required. For example, make sure the certificate works for
> www.example.com as well as example.com (without the www part).

Why should there be a server at both 'http://www.example.com/' and 
'http://example.com/'? (Some browsers auto complete the www prefix, but 
that's no more than common practice, it's by no means any sort of 
requirement.)

You seem to merge the concept of domain name and host name, they're
not quite the same thing, especially with 'www'.

What your studies shows is that the next step up in guessing what to
contact based on a domain name (from http:// to https://) is less likely 
to be a correct guess. Fair enough, I suppose, but these are still 
assumptions (with respect to host name and PKI).

The main problem with this study is that it makes assumptions about the 
architecture of the WWW that are not true. There is a reason why links 
use URIs with a scheme and not just a domain name.

>> However, I think there are two major problems with the study: - the
>> fact it seems to propagate the myth that a cert from a big CA is

Sure, it's not an ideal situation, but it has the advantage that it 
offers a reasonable trade-off between the technical aspect and the 
user-interface aspect of security. (I'm still not fully convinced of the 
benefits of EV, though.)

>> We tend to rely on the UK e-Science CA [1] for a number of
>> machines. Some of my machines with UK e-Science certs score like
>> this: - Certificate: 0 (unknown CA) - Protocol Support: 85 - Key
>> Exchange: 90 - Cipher Suites: 90
>>
>> That would get a "green A" if the CA was recognised. Unfortunately,
>> it's not known by the tool, so it's disqualified. That's a bit
>> harsh, isn't it?
>

It doesn't work for me either (probably some other reason than the 
certificate), but that's the point I'm saying above: I never said there 
should be something at <https://www.ngs.ac.uk/> and no one ever said 
that to me either.

Best wishes,

Bruno.

---

From: Peter Gutmann <[email-masked]>
Date: Wed, 30 Jun 2010 19:41:23 +1200

Nicolas Williams <[email-masked]> writes:

>The subject line is very funny, but, seriously, this doesn't bother me in the
>least.  Why?  Because anyone can put up a site with an invalid, self-signed,
>or might-as-well-be-self-signed-because-no-one-uses-its- root-CA cert.
>Therefore the number of sites with such certs is utterly and completely
>_meaningless_ [m_e_a_n_i_n_g_l_e_s_s_].

It always rather worries me when I see people involved with deploying security
measures make statements like this (not meant as a personal attack on Nicolas,
just a general observation).  There was something similar on the cryptography
list a while back where someone said that having banks accept logins over non-
SSL pages was fine as long as they POSTed the credentials back over SSL, which
showed a frightening lack of understanding of the human factors aspect of how
the security worked.  This is the same thing, the figure is very meaningful
because it supports the analysis of the effects of externalities on web site
security done by some guys at Microsoft Research a few months ago which
pointed out that since certificate warnings are close to one hundred percent
false positives (they were aware of no known cases in which someone had been
saved from being phished by a cert warning), the effect of a true positive is
rendered void.  So a more accurate way of phrasing Nicolas' comment would be:

 The effect of certificate warnings in browsers is utterly and completely
 _meaningless_ [m_e_a_n_i_n_g_l_e_s_s_]

with Ivan's figures and the externalities paper showing why.

>What matters is that the sites that ought to be using HTTPS with valid certs
>are[*].  I'm talking about banks, payment sites, shopping sites that accept
>credit cards, etcetera.

Umm, again not meant as a personal attack here, but have you ever ready *any*
usability studies on the effects of certificates and certificate warnings on
user behaviour?  There are at least one to two dozen out there, and they all
found more or less the same results, that users were so conditioned by false
positives that they saw the cert warnings are nothing more than a pointless
impediment to be bypassed.  If you don't want to read all the HCI papers, just
have a quick look at the Slashdot posts that followed the article about Ivan's
work, those are hardcore geeks (although admittedly Slashdot geeks :-) and all
they're doing is complaining about annoying and pointless cert warnings, so if
that's the geeks' perception imagine what Joe Sixpack makes of them.

Peter.

---

From: Peter Gutmann <[email-masked]>
Date: Wed, 30 Jun 2010 19:47:17 +1200

Tim Dierks <[email-masked]> writes:

>What is being said is that 97% of DNS names that point at SSL servers do not
>validate with those DNS names. This is, on its face, is a statement about DNS
>configuration, not about SSL servers.

It really doesn't matter whose fault it is, what matters is how many users 
will see, and need to click away, cert warnings when they connect.  The user 
doesn't care less which obscure bit of geekery caused it, all they care about 
is that they're seeing yet another pointless dialog that they have to get rid 
of.

>To learn anything interesting about SSL servers at all, more work must be

What needs to be done is to define metrics for what's being analysed.  If you 
want a single figure then I'd use "Will a user connecting with IE6 / IE7 / 
Firefox / (and possibly Chrome) see a warning when they connect?" (to pick 
browsers with > 10% market share).  Why they see a warning is up to the geeks 
to figure out, the important metric in terms of security is what the users 
experience.

Peter.

---

From: Ivan Ristic <[email-masked]>
Date: Wed, 30 Jun 2010 08:50:14 +0100

On Wed, Jun 30, 2010 at 8:35 AM, Bruno Harbulot
<[email-masked]> wrote:
> ...
> (I'm still not fully convinced of the benefits of EV,
> though.)

There's an advantage or two:

- Phishing sites are unlikely to have them
- They work as a defence against phishing & MITM attacks that use
homograph attacks or non-Lating domain names (e.g., paypal.com written
in Russian as raural.com, or something).

---

From: Florian Weimer <[email-masked]>
Date: Wed, 30 Jun 2010 07:51:36 +0000

* Joshua Davies:

> Well, ok, but... why listen on port 443 if you don't plan to support
> SSL in the first place?  I doubt that oracle.com is being run from a
> shared-hosting site.

oracle.com isn't, but www.oracle.com is gosted on a shared IP address.

-- 
Florian Weimer                <[email-masked]>
BFK edv-consulting GmbH       http://www.bfk.de/
Kriegsstraße 100              tel: +49-721-96201-1
D-76133 Karlsruhe             fax: +49-721-96201-99

---

From: Peter Gutmann <[email-masked]>
Date: Wed, 30 Jun 2010 19:59:26 +1200

Nicolas Williams <[email-masked]> writes:
>> > from deploying servers with bad certs. <A0>It's a _fact of life_.
>>
>Maybe, but if there's nothing you can do about this, what do you propose to
>do then?

The first step to recovery is to admit that you have a problem.

In this case we have a very serious problem (close to 100% false positives
rendering cert use _m_e_a_n_i_n_g_l_e_s_s_ - did I decorate that right?) and
if, as you say, there really isn't anything anyone can do about this then we
need to start looking at other solutions, because there's no way we can get
anywhere with the current one.

Peter.

---

From: Bruno Harbulot <[email-masked]>
Date: Wed, 30 Jun 2010 09:09:39 +0100

On 30/06/2010 08:50, Ivan Ristic wrote:
> - They work as a defence against phishing&  MITM attacks that use

I think these protections are a bit flaky in fact.
I'll take an example that I've seen once on a banking website (no need 
for an account to try this).

NatWest is a fairly big bank in the UK: http://www.natwest.com/

The 'Personal Banking' link redirects to: https://www.nwolb.com/
(where presumably, nwolb stands for "NatWest Online Banking").
This has a nice green EV certificate for "The Royal Bank of Scotland 
Group Plc (GB)".

Now, I know that NatWest belongs to RBS (mainly because I follow the 
news and that was said when these banks were rescued by tax-payer money).
If I didn't know and just looked at the stores on the streets, RBS and 
NatWest would seem to be competitors: shouldn't users be a bit 
suspicious to continue using a banking website when it's "green" but 
appears to have a cert issued to a competitor?

If you just educate users to say "green bar is OK", you don't have that 
much more security than the "blue bar". If you tell them they should 
look at the company in the EV certificate, then you can introduce more 
confusion. Thinking about the cert is not a bad thing, but confusion for 
non-tech users can be really bad.

Best wishes,

Bruno.

---

From: Martin Rex <[email-masked]>
Date: Wed, 30 Jun 2010 16:12:40 +0200 (MEST)

> > remove cruft from browser distributions.

For some of the browsers, the inclusion of CA certificates is not
a courtesy and free service to users, but instead requires an
non-negligible financial effort on the part of the CA.
There even was a rumor that for one CA whose cert was in every
major browser, and which went out of business, the hardware box
holding the private key to that RootCA cert was auctioned because
of the value that is associated with having a trust anchor
pre-configured and pre-trusted with a huge installed base.

-Martin

---

From: Steffen Schulz <[email-masked]>
Date: Wed, 30 Jun 2010 18:29:27 +0200

> anywhere with the current one.

Like KCM for all the not-that-important sites. And whereever some more
critical client authentication is involved, the protocol must ensure
that those credentials are only meaningful to the correct server.
Like in client auth via TLS-SRP.

(Now comes the part where somebody replies that this is all solved by
 client certificates and the discussion is closed 'til next time...)

/steffen

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 30 Jun 2010 11:05:32 -0500

>  _meaningless_ [m_e_a_n_i_n_g_l_e_s_s_]

That is quite unfair of you.  I acknowledged that the client side issues
are a big problem.  But I also pointed out that since we cannot prevent
huge numbers of lame certs, we can't focus on the number of lame certs
and say the sky is falling.  For pointing out the obvious I get repaid
with insults.

Rewriting what I wrote as you do, after Ivan and I went over the same
thing earlier, is certainly on the edge of legitimate debate tactics, if
not an outright personal attack, regardless of your disclaimer
otherwise.  Keep the discussion technical, at least for now.  Let's
identify problems, outline the set of possible solutions, then identify
the subset of problems that we can or must solve, then solve them.  Or
if you prefer to attack the problem set some other way then let's hear
that.

Nico
--

---

From: Martin Rex <[email-masked]>
Date: Wed, 30 Jun 2010 18:41:05 +0200 (MEST)

Ivan Ristic wrote:
> > (I'm still not fully convinced of the benefits of EV, though.)
> 

This sound like:

All server certs are equal, but some server certs are more equal than others.

While the basic idea comes down to "reduce the number of
your trust anchors" the current approach first of all
provides a stronger business model for CAs.

Recoloring a part of the browser toolbar is a feature developed
by marketeers.  Unless it is clearly defined how things should
work with protocols (rfc-2818 or draft-saintandre-tls-server-id-check)
this approach is going to create new problems, because it completely
ignores programmatic clients.

-Martin

---

From: Marsh Ray <[email-masked]>
Date: Wed, 30 Jun 2010 16:12:06 -0500

> ignores programmatic clients.

Not only that but it's "opt-in" validation on the part of the guy 
running the server (be they legitimate or attacker). I kinda thought it 
was the job of the CA to do their due diligence in authenticating the 
applicant all along, so now charging an applicant extra for the 
privilege of being thoroughly authenticated does not enhance their 
credibility in my view. Not to mention the reports that some trusted 
root CAs have a practice of issuing "sub CA" certificates. It seems that 
there is an unknown (but non-zero) number of these sub-CAs around, each 
having pretty much full authority to issue server certs that are trusted 
by your browser.

Although this is a subject of great interest to myself and others on the 
list, it might be drifting just slightly off-topic for the IETF TLS 
list. The RFCs that I've read mostly stick to the mechanics of the 
crypto, the data structures, and the protocol itself and (probably 
wisely) stay out of recommending in whom you should place your 
unrestricted trust. So I suggest we steer away from the terms "valid" or 
"invalid cert" unless we include enough specifics to have a meaningful 
discussion in the context of some specific RFCs.

- Marsh

---

From: Seth David Schoen <[email-masked]>
Date: Wed, 30 Jun 2010 15:40:31 -0700

> problem.  I suspect that's not the case though.

In an earlier message in this thread you suggested that "sites that
ought to be using HTTPS with valid certs" were "banks, payment sites,
shopping sites that accept credit cards, etcetera".

I think one of the most positive developments of the past two years
has been the increased recognition that financial information is
not the only information that is private or sensitive, and hence not
the only information that should be protected with HTTPS.  Thus we
have HTTPS available for webmail, search engines, social networking,
an encyclopedia, blogging and microblogging platforms, government
agencies, newspapers, and direct-to-consumer DNA testing services.

Many Internet users regularly give their credit cards (complete with
CVV2!) to strangers in stores and restaurants, maybe a half-dozen
times a day, but would never want the people they encounter in their
daily lives to know what they search for on Google or Wikipedia.  We
can make a lot of progress for privacy and information security by
further breaking the reflexive association between HTTPS and credit
card numbers and the stereotype that there's only one kind of web
site for which HTTPS is appropriate.

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 30 Jun 2010 17:51:10 -0500

> agencies, newspapers, and direct-to-consumer DNA testing services.

Quite true.  All services where user accounts are valuable should be
protected.  That might still be a tiny fraction of the number of hosts
reachable via the Internet and that serve HTTPS :(

> site for which HTTPS is appropriate.

I'd be ecstatic if we knew that at least retail and banking were secure
enough.  That's where I'd start, but maybe I'm misguided.  I imagine
that for many people (e.g., teenagers, who usually have little in the
way of finanacial resources, but much in the way of free time) starting
with social media is probably more important.

---

From: Martin Rex <[email-masked]>
Date: Thu, 1 Jul 2010 01:52:06 +2600 (MEST)

Seth David Schoen wrote:
> have HTTPS available for webmail

*Cough*  you mean like the www.hotmail.com login page?

There are also a number of webmail hosters that restrict the usage
of TLS to the login procedure.

> search engines,

Which of the default search engines or search toolbars use HTTPS?
(btw. https://www.bing.com also hits the wrong akamai servers).

I'm actually more concerned how google snoops my searches
(e.g. with redirecting all hits through itself).

https://www.google.com  calls itself "beta", and doesn't seem to
use Web 2.0 yet.  Security would go down the drain if you would
use the service that is offered at http://www.google.com under
TLS protection because of Web 2.0 -- an attacker could determine
what you type by simple traffic analysis of the encrypted server replies.

> social networking,

Oh yeah, it is very important that the stuff you publish on facebook
is only visibible to its x00 million users and not the rest.  :)

> agencies, newspapers, and direct-to-consumer DNA testing services.

As long as providing content under TLS protection requires a significant
investment on the side of the content provider, it will only happen if
there is a business model to charge those costs back to the consumers/users.

Currently, even those who charge keep a significant amount of their
content outside of the TLS-protected area.

-Martin