Hacker News new | past | comments | ask | show | jobs | submit login

I'm quite sad that they're doing the wildcard thing. There are RFCs stating the problems they cause[0]. It would have been nice to steer people away from this awful security practice.

I wrote a very opinionated and ranty blog post which goes into more detail ( but strongly implies people lazy :( )

https://blog.dijit.sh/please-stop-advocating-wildcard-certif...

[0]: https://tools.ietf.org/html/rfc6125#section-7.2




Do you have an opinion on Sandstorm's use of wildcard certificates and randomized hostnames for each application sesssion? [0] They insist that this provides many desirable security features. (Note that the free HTTPS certificates provided by the Sandcats.io service are renewed every week. [1])

[0] https://docs.sandstorm.io/en/latest/administering/wildcard/#...

[1] https://docs.sandstorm.io/en/latest/administering/sandcats/#...


I'm the tech lead of Sandstorm, not dijit, but let me see if I can interpret his views relative to Sandstorm.

dijit's complaints seem to focus on the case where a wildcard is shared by many logically separate services, as a convenience vs. getting a separate cert for each. This is probably the most common use of wildcards in practice, and it is indeed bad.

None of dijit's complaints apply to the case where the entire wildcard is really served from a single logical service that needs to generate lots of short-lived hostnames for browser-side sandboxing purposes, which is what Sandstorm is doing. Sandstorm is possibly the only infrastructure in existence which is trying to do this at a scale that legitimately cannot be solved without wildcards.

I think dijit is trying to say that each logical service should have its own certificate that does not overlap with any other service. For this purpose, a Sandstorm server is logically only one service, and as long as no other services serve from the same domain, the properties dijit is worried aobut should be no different from a service with a non-wildcard cert.


> In my opinion if you’re lazy enough to warrant a wildcard cert then you’re too lazy to do security properly anyway, period.

You don't present yourself in a way conductive to convincing anyone of anything.



Regardless of the format; the statement still stands, even if it's overly combative. There is functionally no requirement for wildcard SSL that can't be met another way- the other ways in almost all cases are better for user security. Not designing for it (just like not designing for cloud failure) isn't someone being belligerent about nothing it really only emerges out of laziness or unwillingness.

(or, you have a legacy application which is architected a certain way, which is similar in my scenario of having a "non-cloud ready" application.. it's not a good reason to architect things in future this way)


I question the accuracy of an article that claims insurance should make a difference in SSL certificate selection. To my knowledge, the policies on SSL certificate insurance are deliberately and carefully crafted to exclude basically every likely compromise scenario so that no SSL vendor has ever had to pay one out.


I think that's a reasonable assertion, the insurance is not meant for the company it's meant for the user. The /idea/ is that if you are buying something on ebay and the SSL cert says "Ebay.com" then as a consumer your payment is protected from fraud if that entity is /not/ ebay.com.

In reality this almost[0] never happens, but, it's probably rare for a CA to give out certs without some strict checking because of these insurances, not in spite of them.

But yes, I agree that it's not a good argument since it's basically a marketing gimmick and consumers aren't aware of such "protections".

[0]: https://www.cnet.com/news/fraudulent-google-certificate-poin...


I guess if you're the sort of person who buys $1 nonsense on eBay this could even sort-of work.

But if you bought something actually valuable, the insurance is useless _even if it paid out_ which it never has. This is because the huge headline dollar value is the _total_ sum insured and individual claims are strictly limited to a far smaller amount.

Let's try an analogy. Imagine if Coca-Cola took out $10M insurance against Coke causing brain damage. Then it turns out Coke has caused serious and irreversible brain damage to everyone in the world who drank it in the last 50 years. Oops. The insurer says OK, just individually post us proof your brain damage was caused by Coke and you'll get 5¢ each. It won't cover the cost of postage, but too bad, up to 200 million people can claim on this insurance, and at $10M total that's five cents each so that's the maximum claim.

That's how the SSL "Insurance" works. People who can prove they reasonably relied on the insured certificate AND can prove they were damaged financially as a result can claim up to a fixed tiny sum of money, which isn't worth doing.

The insurance firms selling it know this is worthless, it would be illegal to sell such pointless insurance products to consumers in most of Europe, but fortunately they sell it to the Certificate Authority which isn't a consumer, and the CA has no reason to care that it's useless, it sounds impressive.


LE already supports SAN, which seems like it would cover quite a few of the reasons people want wildcards already, shouldn't it?




Consider applying for YC's Spring batch! Applications are open till Feb 11.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: