
Let's Encrypt now holds 35% of the market - tarellel
https://nettrack.info/ssl_certificate_issuers.html
======
013
I think Let's Encrypt is great and their certbot tool makes it even better.

With Wildcard certificates coming to Let's Encrypt, I think they will only
increase in users. ([https://letsencrypt.org/2017/07/06/wildcard-certificates-
com...](https://letsencrypt.org/2017/07/06/wildcard-certificates-coming-
jan-2018.html))

~~~
frik
How about distributing Let's Encrypt?

Do cloud hoster offer a copy of the service from their datacenter? Otherwise
it could be a single point of failure / single attack vector, right?

~~~
stephenr
Their infrastructure is meant to all be HA from memory, and unless you're
doing stupid things like caddy did[1] small windows of downtime shouldn't
cause much issue for ongoing operations anyway - you will likely be starting
to attempt renewing certs weeks before they expire.

1:
[https://github.com/mholt/caddy/issues/1680](https://github.com/mholt/caddy/issues/1680)

~~~
hkeide
Wow, that Caddy thing is pretty scary, thanks for pointing it out. I wonder
what other decisions like that lurk under the surface.

------
shpx
I doubt the web will ever be fully encrypted. There will always be tons of
people who don't care enough. I've come across dozens of high information
static websites that were set up like 10+ years ago where the author will
probably never be back to configure tls.

It's so strange that you have to ask someone's permission to use
encryption[0]. Certificate authorities should've been (should be?) optional.
SSH came out around the same time and its Trust-on-First-Use is a much better
system.

[0] [https://www.tedunangst.com/flak/post/moving-to-
https](https://www.tedunangst.com/flak/post/moving-to-https)

[https://en.wikipedia.org/wiki/Trust_on_first_use](https://en.wikipedia.org/wiki/Trust_on_first_use)

~~~
ehsankia
Honestly question, is there any reason why a static website should have SSL?
Unless you have encrypted DNS, whoever is stealing the data will know the
server you're connecting to, and therefore will have all the exact data
anyways. So HTTPS is quite literally a waste, no?

Sorry for the ignorance, it's a legitimate question.

~~~
cesarb
Even if the site is supposed to be static, an active attacker can still inject
dynamic code into it.

In one somewhat recent example, a non-HTTPS page was modified in transit by an
attacker to inject Javascript code which did a denial-of-service attack
against github. Had the page used HTTPS, the attacker would not be able to
inject that Javascript.

~~~
upofadown
Then perhaps browsers should not execute any code from a non-HTTPS source.
That would nicely cover the old static page case. Any modifications to the
html would be visible to the user.

~~~
mtberatwork
If the malicious JS is served over https, it could still be inserted into a
static page served over http without the user knowing. The static page needs
to be served over https to avoid tampering from MITM attacks.

~~~
upofadown
The browser would obviously have to be smart enough to mark code that came
from any sort of http source, even those embedded in https pages or https
loaded by http pages, as non-executable. That would probably be the easiest
way to do it anyway. Once we hit http, the level of trust drops and stays
dropped.

Having thought about this a bit more, that would be an browser option that we
could use today without any general convention. Turning on the "No script
execution without https" option would break very little and would prevent more
than just MITM attacks.

------
hosh
I'd be interested to see whether the total numbers of SSL sites has expanded
because of LetsEncrypt.

I remember, one of the arguments that the Comodo CEO had on the forum was a
rant about LetsEncrypt attacking their business model. While there were a lot
of weird things in that rant, it does seem reasonable that a free service will
erode the paid, commercial offering. So I would be curious if Letsencrypt is
enabling people who otherwise would not have gotten an SSL cert, as well as
the extent Letsencrypt is taking away customers.

I would also be curious to see what happens when wildcard SSL certs are
launched.

~~~
schoen
[https://www.wired.com/2016/04/scheme-encrypt-entire-web-
actu...](https://www.wired.com/2016/04/scheme-encrypt-entire-web-actually-
working/)

> And because 85 percent of those sites never had HTTPS before, it's already
> significantly boosted the total fraction of sites that are encrypted on the
> web as a whole. Based on numbers Mozilla gathers from Firefox users,
> encrypted sites now account for more than 42 percent of page visits,
> compared with 38.5 percent just before Let's Encrypt launched. And Aas says
> that number is still growing at close to one percent a month.

(I work on Let's Encrypt.)

~~~
berbec
This is something that is going to save a company I work for thousands
annually. Extended Validation certificates for dozens of domains and
subdomains. Now we just plug certbot into crontab and forget about it,
forever!

Thank you for all the work you do. It is a great service you have given the
world at large.

~~~
schoen
By the way, the Let's Encrypt certificates are Domain Validation (DV)
certificates rather than EV. Hope that's still OK for your application!

~~~
berbec
We don't do any sort of major ecommerce and I have never drank the EV Kool-
aid. It's the same encryption either way, just EV has an extra CA "stamp of
approval". Considering how much I trust your average CA[1], i.e. not at
all[2]...

1:
[https://www.infoworld.com/article/2623829/authentication/wea...](https://www.infoworld.com/article/2623829/authentication/weaknesses-
in-ssl-certification-exposed-by-comodo-security-breach.html) 2:
[https://www.pcworld.com/article/249242/verisign_hacked_what_...](https://www.pcworld.com/article/249242/verisign_hacked_what_we_dont_know_might_hurt_us.html)

------
eastern
Dropping marketshare for others may not mean falling business. It's possible
that the market size is growing fast enough for the commercial ones to
actually be seeing a growth in business.

~~~
ridgewell
I also really wouldn't be surprised if Comodo's market share is inflated from
the free SSL certificates that Cloudflare offers for all its users.

~~~
tialaramex
Is your hypothesis that Cloudflare doesn't _pay_ them for those certificates?

How about cPanel and others who bundle Comodo certificates?

No, I think Comodo are doing very nicely off this. They've correctly judged
that they're never going to be the Maserati in this industry they need to be
Ford or Toyota and too bad if some people sneer.

------
IgorPartola
It is hard to compete with free. I think if some CA made things as easy as the
ACME protocol and the associated tools did, yet still charged $9/year, it
would have delayed things a bit. But the end result would have been the same:
$0 is the winning price.

~~~
gioele
> $0 is the winning price.

The weird (and pleasant) thing here is that the $0 price is backed not by a
shady business, but by a non-profit [1] that hires a stellar team of
TLS/DNS/Internet experts that does most of its job openly and in a replicable
way.

[1] Internet Security Research Group (ISRG)

~~~
ersii
That doesn't mean that things will be pleasant forever. There are plenty of
shady non-profit organizations.

~~~
anilgulecha
Though the stack being FOSS means it's easy to move to a new org when this
happens.

~~~
hdhzy
It's not that easy. I mean the code is there but the infrastructure needs to
be provisioned and it takes time to gain trust in the CA world, see CACert.

~~~
tialaramex
CACert is a weird example because their model was completely at odds with how
everybody else (yes now including Let's Encrypt) does things.

CACert says this is trustworthy because you have to know somebody who knows
somebody who knows somebody etcetera. The profiles with a single photo of a
swimsuit wearing young woman and a generic-sounding name that say they know me
from school on Facebook every few weeks can tell you what happens to that idea
at scale.

In contrast all the trusted public CAs (commercial or not) have a bunch of
employees either directly making validation decisions according to some
company policy or writing software to automatically make such decisions.

In theory maybe CACert's model really could work, but what it definitely can't
do is work the same way as everybody else. So it was very hard to get anyone
to give them a chance, still less after they started to have internal
squabbles.

You are correct that gaining trust takes time, but what a conventional CA does
(with the exception of maybe Verisign and Thawte which are _really_ old) is
they first get an existing trusted CA else to sign a subCA certificate saying
they trust the new CA. The ordinary "Let's Encrypt Authority X3" certificate
is signed by IdenTrust (it says "DST Root CA X3" on it but the Digital
Signature Trust no longer exists). There's another copy of the same
certificate signed by ISRG, but that's only trusted in much newer software.
Modern Firefox, current macOS or iOS, but not say, Internet Explorer 10

~~~
hdhzy
> CACert is a weird example because their model was completely at odds with
> how everybody else (yes now including Let's Encrypt) does things.

Well, CACert insisted on validating people but it turns out that it's not
really necessary to know your customer to issue DV certs according to Baseline
Requirements. Let's encrypt understood it and just did a minimal required job
to be accepted (it's still a lot of work).

Instead of verifying people I'd gladly see X.509 replaced with OpenPGP w.r.t.
trust model so that I could see who trusts who and why. OpenPGP has a mode of
hierarchical trust with trust signatures, additionally they can be limited to
a domain, that could be used to give people power to issue their own
certificates for their own domains.

------
systematical
Honestly I've been holding back on going with lets encrypt at my 9-5, partly
because certificates through namecheap/comodo are only $9.95 per year. I'm
surprised by how much market share it has already, time to jump on board. I
imagine paid for certificates will be dead in a few years.

~~~
gregmac
I recently have been working on moving a chunk of our infrastructure to a
fully automated deployment. It consists of several micro services on various
subdomains within 3 top level domains.

For the dev and staging environments, I used a sub-domain prefix:
app1.staging.example.com, downloads.staging.examplecdn.com, etc. There's a
script that looks through the deployed systems in it's environment and
configures the proxy server appropriately -- including running certbot if
needed to get certificates.

I used let's encrypt initially so we could actually test real SSL without the
hassle of new certificates, especially when we wanted to deploy a new
environment. It worked so well we just left it in when we deployed to
production.

The cost of certificates is nothing compared to the effort to get someone to
put it on the company card, renew it (and answer questions about what it is a
year from now, yes we still need it), manage the private key, etc. Let's
Encrypt is better in every way.

~~~
joering2
Lets Encrypt provides wonderful services, but don't forget in business when
something is free, it might end up costing you money.

Not only these certs are for 3 months, but what if their renewal services have
hiccups. Not wishing them anything bad, but I can imagine that for whatever
reason (including root cert being invoked if they happen to encrypt sites that
normally wouldn't do like c.p.) I imagine that 35% of net rushing to a local
cert provider to get a paid solution or face no traffic to their site at all.

Besides, the times of Thawte's 1999 when single cert was $150 are long gone;
you can get a decent Comodo for $4.99 per year these days.

~~~
vertex-four
Due to the lack of automated renewal procedures, I've seen many more small
websites die for a day or so once a year with "traditional" certificates (when
people forget to manually renew) than those with certificates maintained via
letsencrypt.

The actual solution to this should be for any of those providers to provide
the ACME certificate management protocol, and then if letsencrypt fails, I can
point certbot at it.

~~~
Fnoord
There's always going to be stuff which is automatically renewed while you
don't want to, or stuff you need to manually renew when you have to.

I have a wonderful suggestion for anyone who wants to combat this problem: put
the end date in your agenda! If you're a busy person put multiple
notifications about it, or learn to look in advance in your agenda.

~~~
vertex-four
I don't think there's any situation I've seen where I don't want my
certificates to be renewed. As a sysadmin, the more repetitive tasks I can
automate, the better.

~~~
Fnoord
You must've seen automated subscriptions which you did not want to renew?

My comment was more a general statement to combat a type of procrastination (a
deadline which must be met slightly before its date), specifically with the
mechanic of both automated and manual subscriptions. Calendar reminders work
wonderful with _both_.

I can also think of various scenarios where you don't want certificates to be
renewed. Or well, maybe _you_ don't but the _users_ would. Like for example
when your server no longer works, or got confiscated. A low timeout aids in
lowering the amount of those certificates.

~~~
vertex-four
Automated payments are a different matter from automated infrastructure that's
already been paid for.

I have automated tickets created when I need to do things that I haven't
automated yet, but, I still want to automate as much as possible.

I have not run into the problems that you're suggesting I should've. If a
server no longer works or was confiscated, why would I still have DNS pointing
at it? And does it really matter if I have some servers renewing certificates
unnecessarily anyway?

------
sigjuice
I hope Let's Encrypt does S/MIME certificates someday. Almost all major email
clients support it.

~~~
tialaramex
Let's Encrypt isn't interested in S/MIME. You are, of course, welcome to try
to repurpose their software and/or the ACME protocol to provision S/MIME
certificates.

Although S/MIME isn't a real Wild West like some types of X.509 certificates,
it has seen much less oversight than SSL/TLS ("Web PKI") certificates. There's
also not really a great appetite for cleaning it up. If you want to be the
hero in this story there's definitely an opening for that.

------
coldacid
If all you need is basic domain validation, which is the case for pretty much
any site that just wants encryption and doesn't need real identity validation,
Let's Encrypt is good enough. Add their tools for quickly generating and
updating certs (so long as you're not using IIS) and it's no surprise that
they're leading now.

~~~
jamiesonbecker
Agreed, but with the exception of EV-SSL/TLS, certs are fungible and therefore
no site _needs_ 'real' identity validation, because you can't actually see the
identity anyway (short of running cert patrol or opening up the details page).
It's also a crying shame that chrom* hid those details in developer tools now
-- when before, at least, you had a fighting chance of seeing
crypto/expiration/etc details. (Of course, with DV certs being treated the
same as OV certs, someone with a DV cert could just forge all of the metadata,
as long as they control the domain; DV CA's don't verify the metadata, by
definition.)

In other words, I remember faxing data into verisign or thawte back in the day
(not even that long ago), but OV is just not worth paying for anymore: OV
provides zero value, now that DV certs are accessible. Someone who had access
to your domain could just get a DV (or LE) cert and no one would be the wiser.

I'm not sad to say that Comodo wrote their own death certificate (ha) by
racing to the bottom. It's hard to beat free and open source.. the only thing
they've got to hold onto now is EV, and that's of diminishing value now as
well.

~~~
schoen
> (Of course, with DV certs being treated the same as OV certs, someone with a
> DV cert could just forge all of the metadata, as long as they control the
> domain; DV CA's don't verify the metadata, by definition.)

The Baseline Requirements require certificate authorities to be able to verify
the correctness of the information that they include in each certificate --
including for DV. See the first subsections of section 3.2.2 of

[https://cabforum.org/wp-content/uploads/CA-Browser-Forum-
BR-...](https://cabforum.org/wp-content/uploads/CA-Browser-Forum-BR-1.5.4.pdf)

~~~
jamiesonbecker
Good link, but you should read it more carefully. That metadata (i.e.,
Organization) is only verified if the certificate is purchased for that
purpose. In other words, would you like us to do extra organization
validation? pay more. otherwise, it's cheaper if we only validate the domain.

It's kind of crazy, actually: it's more expensive for you to prove who you are
than it is for the attacker to NOT prove who they are. Security should be
about raising costs for the attacker, not _lowering_ them!

And, as you know, neither Let's Encrypt or any other DV CA's check or verify
any information except control of the domain itself.

That's why those certs are called Domain Validated instead of Org Validated ;)

~~~
pfg
This is not what the Baseline Requirements state and it's also not how
issuance works in practice. The validation requirements for things like
"Organization" always apply "[if] the Applicant requests a Certificate that
will contain the countryName field and other Subject Identity Information."

If you submit a CSR with any of these fields, and you're requesting a DV
certificate, the CA will discard those fields. Any sane CA implementation will
cherry-pick only a whitelisted set of fields from the CSR, make sure the
values have been validated according to the Baseline Requirements and root
policies, assemble the certificate from that data and sign the result,
ignoring all other fields (or discarding the request).

CAs that run something like sign(user_submitted_csr) would not last long in
any of the major root programs.

------
ToFab123
I wish they would make Microsoft IIS a first class citizens. If they are true
to their mission they should set any political reasons aside, and provide
official support for all platforms. AFAIK there are no technical reasons that
prevents them to implement support for IIS and Azure Web Sites. There are a
number of user created solution for both, that works well, but i would feel
more comfortable with using that in production with official vendor support.
So either Microsoft should fund this or lets encrypt should and i wonder why
none of them has.

~~~
jaas
Let's Encrypt doesn't directly produce any client software. ACME clients are
built by our community and the community builds what they feel like building.
If something hasn't been done yet, or isn't where you want it to be, that
reflects community priorities, not our politics.

We'd love to work more closely with Microsoft. We've been talking with
Microsoft and various Microsoft community members about building great support
for IIS since before Let's Encrypt launched.

~~~
ToFab123
Thank you for clearing that up and my apologies for implying political
motivation on your side!

------
sAbakumoff
Apparently those 35% do not include samsung.com which does not use
[https://](https://) at all, really!

~~~
coldtea
To hide the fact that you're shopping from Samsung?

~~~
quickthrower2
DNS ain't encrypted afaik. Snooper can see that you visited the site but not
which url.

------
Fej
Which (shared) web hosts remain opposed to Let's Encrypt?

Namecheap (my host, until I get around to switching) still is, for business
purposes. (their customer service rep gave me some BS about "security" as to
why, but it's really because they make a ton of money selling certs)

~~~
schmappel
I use Namecheap too. Which host would you consider switching too?

~~~
AnsemWise
Also wondering this

------
raides
Putting all our eggs in one basket? This has never gone bad for the security
field, right?

~~~
tscs37
Nothing stops any of the big CA's to offer their own ACME endpoint. It's an
open standpoint based on software that is on github.

Running a ACME authority is not hard. The CA's just don't want to cannibalize
their business.

~~~
tialaramex
At least one major commercial CA does offer ACME to paying customers. If you
want ACME and want to use their CA, and have whatever their entry level
enterprise price is burning a hole in your pocket, they will take your money.

They basically position it as "As well as integrating with Windows we also
make everything work automatically with your weird Unix stuff like Apache or
nginx" but it's an ACME service under the hood.

ACMEv2 (the Internet Standard RFC when that finally gets published) is a bit
nicer for a commercial CA because it spells out how you use ACME to say e.g.
"Hey, I'm paying customer #383829, here is proof - give me certificates on my
account". The only easy way this could have worked in ACMEv1 wasn't terribly
compatible with the limited understanding of cryptography that say Steve in
accounting has.

------
gh0stbrain
I think this is fantastic, it's amazing to see how Let's Encrypt just blasted
off. It kind of scares me, one company having such a large presence, but I
think it's one of the best companies it could have happened to. :)

------
greggman
good ! certs shouldn't be only something for people with $$$.

~~~
randomstring
Agreed. Paying someone money for a bag of random bits is criminal.

~~~
icebraining
The random bits are provided by the client. The CA signature is definitely not
random.

~~~
tialaramex
Fun fact: The serial numbers are required to be random! They're unique, but
random (since they are huge numbers there's no problem achieving both).

This is done because it reduces the danger from collision attacks of the sort
which worked on MD5 and are likely to be possible for SHA-1. The random serial
number makes it impossible to guess what the signature on the certificate
you're getting will be before it's issued to you, so you can't use a collision
attack (other types of attack could work, but those have never turned out to
be practical on a modern crypto hash even when it's "broken" like MD5).

They chose to make the serial numbers random because that's near the start of
the certificate document and collision attacks are only defeated by randomness
that happens as early as possible in the document.

------
ryanSrich
We use Let's Encrypt for new environments at Datica [1]. It's one of better
features we've implemented. LE is one of the better companies out there. Truly
doing useful work.

1\. [https://resources.datica.com/compliant-
cloud/articles/guides...](https://resources.datica.com/compliant-
cloud/articles/guides/lets-encrypt/)

------
JeanMarcS
I'm not sure it's the good way to present this (or phrase it). It's more that
their presence enlarge the number of HTTPS sites (or service) by 50% (totally
thumb in the wind estimation :-D ) than "stealing" customers to other
companies.

Of course there's a part of migrating certificates to Let's encrypt, but I
find it more important that the HTTPS surface had grown that much.

~~~
tialaramex
For the top 10 million sites examined by w3techs (which looks at sites to see
if they use technologies like PNG, WebM, embedded fonts, whatever) HTTPS went
from under 15% to almost 50% since they started measuring. Less than half that
growth is Let's Encrypt, their growth is still spectacular, but to put things
into perspective, if they had the _same_ growth and the whole HTTPS market
didn't grow they would now control 110% of the market, yet in fact every other
major CA grew at the same time.

------
megaman22
I get that HTTPS is good for anything that's got sensitive data, but what
really is the point of enabling it if you've got a static, old-school
informational page? Aside from avoiding getting dinged by search engines?

~~~
Matt3o12_
There are a couple of reason. Encryption also preserves the data integrity.
That means your ISP cannot inject ads or tracking scripts. I’ve heard that
this is already quite common in some countries (including mobile services in
the US). This also means that nobody who sits between the server and your
internet connection can inject falsified information into that static page.

You also have more privacy. An attack can see that you are accessing Hacker
News but not necessary what comment section you are on (though it can
sometimes be inferred by the page size).

You might not care about that about your oldschool static side but someone who
lives in suppressive countries might because it might make a big difference if
they only access Hacker News for the latest and trendiest node framework or if
you actively research the comments about articles how your country does
something bad.

------
nkkollaw
Well, it's free and easy-to-use...

They need wildcard certs and they'll go to 90% (some companies will still need
to use more "reputable" companies).

~~~
wnoise
Wildcard certs are coming in January.

~~~
nkkollaw
It's truly amazing what a blow to the industry this will be, and apparently
out of nowhere.

99/yr for a cert was too much, though, and everything very cumberstome
compared to Let's Enctrypt

------
fivesigma
Let's Encrypt is great.

I would like to see native ECC support and a more stringent validation mode
that allows more than 3 months of certificate lifetime.

~~~
jaas
More stringent validation methods won't help with the ever-present possibility
of private key compromise. So long as that's a real possibility and revocation
is broken (which it clearly is), longer certificate lifetimes are a liability.
Renewal needs to be automated so you don't care how often you have to renew.

Let's Encrypt will sign your ECC keys now, but we'll sign with our RSA keys.
We'll likely have our own ECC trust chain some time next year.

------
sandGorgon
Is anyone using letsencrypt using nginx+docker ? How do you take care of the
chicken and egg situation when you spawn a nginx docker container - nginx
cannot start without a valid certificate and you cannot generate a valid
certificate without nginx.

I haven't looked into this for about six months - I just bought a wildcard SSL
certificate for 70$ and called it a day.

~~~
osrec
Just wondering, why do you need nginx started to generate a valid certificate?

~~~
klodolph
The Let’s Encrypt client validates your server by placing a file on your
website at a specific location.

There are other ways too, but this is the easiest.

~~~
tscs37
If the server isn't started yet, the easiest way is to use the HTTP
validation. Once it's started placing the file is easiest. You can use both
methods.

------
collinmanderson
Would be nice to see the graph in absolute terms. - How much of this is people
switching from other companies to Let's Encrypt, and how much of this is more
websites getting SSL?

------
krisives
Does this count parts of the market that will be gone soon? Legitimate
question didn't Starcom recently say they won't issue new certs and will shut
everything off in 2020?

~~~
kijin
StartCom hasn't had its own market share since late last year when most
browsers distrusted it. It's been reselling certs from Comodo and Thawte,
probably contributing to the market share of these other vendors.

~~~
krisives
Thanks for reminding me I had forgotten about that

------
BuleBule
After spending a ton of money on SSL certs over the years, I not only salute
Let's Encrypt but also fart in the general direction of those orgs who fail to
support it.

------
gumby
Why on earth is it only a third? What value do the other providers offer?
(other than EV I mean, but most uses don't require that).

~~~
morgante
Even though automated renewals are absolutely superior, as encouraged by LE,
they do require some work to adopt. For a lot of businesses, it's easier to
have someone manually renew every year or two than to do the migration work of
setting up automated LE certs.

~~~
davb
Not only setting up, but monitoring.

------
covenator
Yet Hostgator does not have LetsEncrypt for shared hosting users. Guess their
paid SSL is too profitable.

------
m-p-3
I'm waiting for wildcard support and then I'll switch.

------
rufi
i have used its very simple to configure with cerbot and best of all its free

------
likelynew
Where is cloudflare?

~~~
stephenr
Cloudflare aren't a Certificate Authority, they use Comodo certificates.

------
avodonosov
I hope this will let them to be profitable.

------
ringaroundthetx
Side note: I use Amazon certificates (ACM) and I had someone try to "verify
me" using Extended Verification procedures, ACM doesn't have EV, it is listed
as one of the limitations, but the real question I have is:

What is Extended Verification

Why would I want Extended Verification

Why would I look more legitimate to someone looking for Extended Verification?
Because my business/personal information would be associated with the
certificate or something?

~~~
Ajedi32
I assume they mean Extended Validation?

Basically the only difference is that it gets you a green badge in the URL bar
with the name of your business:
[https://i.stack.imgur.com/xmMnB.png](https://i.stack.imgur.com/xmMnB.png)

In practice, very few sites actually need EV. Domain validation is usually
enough. (Troy Hunt wrote a pretty good article on this a while back:
[https://www.troyhunt.com/on-the-perceived-value-ev-certs-
cas...](https://www.troyhunt.com/on-the-perceived-value-ev-certs-cas-phishing-
lets-encrypt/))

~~~
Kliment
Interestingly, apparently Twitter has switched to EV since that article was
published. Not sure if any of the other big10 have also.

~~~
pfg
I'm not sure if this is still the case, but for some time, Twitter served both
EV and non-EV certificates depending on where the visitor was located. I don't
think they ever publicly explained this behaviour.

~~~
hsivonen
Which, of course, is the worst way to use EV, because it makes both users who
expect EV and notice when it's missing worried.

------
nurettin
Could https be used to track persons on the internet using some phase of the
protocol? Perhaps the "random" number generated after a handshake is not so
random and actually identifies you as a user?

Sure, your communications are encrypted by what people perceive as an
infallible algorithm, and all serious websites with forms force you to use it,
but at what cost?

~~~
quickthrower2
What about a session cookie?

~~~
nurettin
It is obviously very easy to evade cookies and IP tracking, so I'm not even
sure why these are suggested.

However, if the https protocol itself is bugged at the TLS level, what can you
do? What if the last few bytes of the ssl session number are always generated
according to your unique hardware specs? What then?

I'm aware that this looks a lot like FUD, but it is rather a question, because
I'm not peddling an alternative. Why implicitly trust any protocol?

