Vulnerable StartEncrypt enabled mis-issued StartSSL certs


#1

Wow… Just wow… What did I just read:

I’ll just copy/paste the conclusion of the article:

StartCom launched a tool that makes it easier to secure communications on the internet, which is something we applaud. In doing so however, they seem to have taken some shortcuts in engineering. Using their tool, an attacker is able to obtain certificates for other domains like google.com, linkedin.com, login.live.com and dropbox.com.

In our opinion, StartCom made a mistake by publishing StartEncrypt the way it is. Although they appreciated the issues for the impact they had and were swift in their response, it is apparent that too little attention was paid to security both in design (allowing the user to specify the path) and implementation (for instance in following redirects, static linking against a vulnerable library, and so on). Furthermore, they didn’t learn from the issues LetsEncrypt faced when in beta.

But the issue is broader. As users of the internet, we trust the CA’s to provide us with a base for trust upon which we do business and share our lives online. When a single CA publishes software with this level of security, the trust in the CA system as a whole is undermined.

That’s serious. Very serious… Hopefully only the trust in StartSSL will decline, not CA’s in general.

And… Why didn’t StartSSL just use the ACME protocol? Why try to reinvent the wheel and think you can do ‘better’ than all those hours of thinking, debating and hours of work that went in the ACME protocol?

I’m very interested in all your opinions :slight_smile:


#2

Very interesting read. Amazing how many things they got wrong … and still doing odd things ( like releasing an upgraded version that has the same version number !!!)


#3

Yeah. This isn’t the first vulnerability StartCom has had either. I remember a number of others.


#4

That’s really impressive (in a negative way). Especially how such a company can produce such a bad client (and API) with so low security standards. Take the 0666 permissions for example - that’s such a simple, but bad mistake…

That happens if they try to push a thing out in a very fast time. I assume they were under pressure,… (you know by whom :smiley:)

I mean I do not dislike StartSSL/Startcom in general, but they have made one thing fundamentally wrong: They developed their own client & API here. I mean they could have just used the same standard as Let’s Encrypt - the ACME protocol -, which is well-designed, tested and already deployed in practise. They could have used it to easily implement their own automated certificate issuance in a secure way. If they would have done so, they could have avoided many of these vulnerabilities… And they would also be compatible to many already existing LE clients.
However they have choosen not to do so. Now they see the result…


#5

How the f are they allowed to still run a CA?

Can they just start new projects without any auditing? This is appaling.


#6

I’m wondering if these kind of mis-issues will have consequences for the inclusion of their root certificate…


#7

ouch. this just hurts.


#8

Hey, good news finally. They have learned their lesson:

Eilat, Israel - 4th July 2016 Update

StartCom always try hard to provide best free SSL certificate service for worldwide customers, this is why we have released the StartEncrypt, but due to the time tight and lack strict test before release, there are many bugs in the current version of StartEncrypt, so we decide to stop this version and start to work for new version that based on ACME protocol, we think this is a best choice for more security and more transparency. Very thanks to all valuable feedback, we appreciate all help to improve our products

https://www.startssl.com/NewsDetails?date=20160606


#9

@rugk that is good news indeed !


#10

Better late than never.


#11

When they say “based on ACME protocol” I wonder if that means it’ll actually use the ACME protocol, or if they’re planning to introduce a bunch of unnecessary changes to it before using it. Hopefully not the later.


#12

I disagree. The less trust people place in CAs the better. The whole system is pretty broken - all it takes is one CA screwing up for the whole system to be broken. (As we’ve seen here.)

Unfortunately there doesn’t seem to be a better alternative though, and the CA system is still better than nothing.


#13

Well… I think one thing they have to do is to add the ability to get OV/EV certs. So they have to authenticate the user, but that’s already done with account certs in ACME, so this is also possible.


#14

actually there is.

DANE over DNSSec is a great idea, it sadly hasnt been put in browsers yet but with the tree structure it is a lot less vulnerable than the CA system


#15

I hope you are right. If they just stick with ACME as is then create a branded client and someone complains about how it wont work for them they can point to the myriad of other clients already made.

Besides that, they would save themselves a huge amount of pain and hassle by sticking to what has already proven to work.


#16

DNSSEC & DANE are very disputable subjects.

See e.g. http://sockpuppet.org/blog/2015/01/15/against-dnssec/ and http://www.theregister.co.uk/2015/03/18/is_the_dns_security_protocol_a_waste_of_everyones_time_and_money/.

However let’s rather not continue this subject in this thread as it is off-topic.


#17

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.