AlwaysOnSSL – A free and automated CA | Hacker News Reader

AlwaysOnSSL – A free and automated CA

alwaysonssl.com

93 pointstvvocold53 comments

The lack of an obvious revenue source feels like the business equivalent of a code smell. Let's Encrypt is clearly being run as a charity - with a list of sponsors that are paying for this.

No obvious revenue stream feels like it's a recipe for something that's going to go poof rather quickly.

this also turned me off. It's backed by a for-profit company which can be sold/acquired anytime. If we have learned anything from DigiNotar, Startcom, etc? Trust is a dangerous commodity to have changing hands.

Anyway scrolling down to the bottom¹ they seem to be resellers for DigiCert/Symantec certificates. So based on their strategy to fish for users with free certificates, I'd strongly question both their motives and their track record with handling the technical requirements for operating a CA. If they are a serious actor in this space then they should at the very least have either ETSI TSP² or WebTrust³ certifications to meet the security/trust requirements for operating a CA. Judging from the info on this site, I doubt they do.

¹ https://www.certcenter.com/company/terms

² https://portal.etsi.org/tbsitemap/esi/trustserviceproviders....

³ http://www.webtrust.org/item64428.aspx

>they seem to be resellers for DigiCert/Symantec certificates

>they should at the very least have either ETSI TSP² or WebTrust³ certifications to meet the security/trust requirements for operating a CA

A reseller does not need to meet any of these certifications. Resellers have a business relationship with a CA, and all the steps related to certificate verification and issuance are handled by that CA.

On the backend, a certificate request for your site is handled the same by the CA whether if comes through a reseller or through them directly.

Also, they don't say which person(s) are actually running the company: https://www.certcenter.com/company/imprint

I actually thought that was a legal requirement in Germany.

They do on the German site: https://www.certcenter.de/company/imprint

Not to mention SSL shouldn’t be on anywhere anymore. Such a misnomer.

This is a tragically insecure site already; the only thing keeping JS injection at bay is apparently regex matching for `script` in the id-verify page.

Note: it does not filter for SCRIPT. e.g.: https://alwaysonssl.com/id-verify/%3Ch1%3E%27%27%3B%21--%22%...

Dangit, Chrome is keeping me too safe:

> This page isn’t working

> Chrome detected unusual code on this page and blocked it to protect your personal information (for example, passwords, phone numbers, and credit cards).

> Try visiting the site's homepage.

> ERR_BLOCKED_BY_XSS_AUDITOR

EDIT: Firefox let me load it fine. Turns out their CSP at least prevents execution of that snippet. Smart.

Precisely. This should not be a thing that can happen on a page that allows one to request and receive certificates rooted in trust stores.

Content security policy seems to block this for me, so at least there is that.

    Content-Security-Policy: default-src 'self'; script-src 'self' platform.twitter.com syndication.twitter.com gitcdn.github.io code.jquery.com maxcdn.bootstrapcdn.com cdnjs.cloudflare.com dcggld9bcojs3.cloudfront.net; img-src data: 'self' dcggld9bcojs3.cloudfront.net; style-src 'self' 'unsafe-inline' gitcdn.github.io maxcdn.bootstrapcdn.com cdnjs.cloudflare.com; font-src 'self' data: ; form-action 'self'; child-src 'self' platform.twitter.com; connect-src 'self' syndication.twitter.com;

I'm not entirely sure why gitcdn.github.io is on list of allowed script paths, but at least XSS injection is not straightforward, to run scripts, you need to hijack one of those hosts.

---

As for insecure claim, it does have an XSS attack, but Content-Security-Policy reduces its impact to minimum. You cannot make do a request to an arbitrary domain by loading an external resource. So even if one part is insecure, the other one prevents an attack - security in depth. Of course, they still should fix that XSS attack.

I also decided to check if they don't sign certificates for domains that disallow this (by means of CAA DNS record). They properly do, as SSL baseline requirements say, so nothing to report.

Whitelisting entire CDNs like that is incredibly dangerous, see https://github.com/cure53/XSSChallengeWiki/wiki/H5SC-Minicha...

Oh, you are correct. This will only delay an attack.

There is however some sort of firewall preventing using `<script>` tag.

> You cannot make do a request to an arbitrary domain by loading an external resource.

Not true; thanks to style-src 'unsafe-inline', <style>:root{background-image:url(https://example.com/)}</style> will work just fine.

They didn’t do a good job with protecting against injection, but at least they have a generally decent CSP, which stops inline JavaScript.

However, the CSP does include style-src 'unsafe-inline', so you can basically just hide all of their content and put just about whatever you like on the page, but not actually execute anything directly:

https://alwaysonssl.com/id-verify/%3Cstyle%3Emain,.jumbotron...

Or even use a meta refresh to make it redirect to somewhere you control:

https://alwaysonssl.com/id-verify/%3Cstyle%3Emain%7Bdisplay:...

> We do not support ECC (Elliptic Curve Cryptography) at this time; but we work hard! We also do not support RSA keys >2048 bit.

Hrm.

Interesting... This is the email I got when I requested an S/MIME - Symantec - seriously?:

Dear customer,

Your order request for Symantec Digital ID for Secure Email(S/MIME Class 1) for the email address christian@perspecta.ca is received.

You need to approve or reject the request using following URL:

https://alwaysonssl.com/id-verify/GX5aT6H2vG8s-Td2CLOBBEREDC...

For any further queries please visit:- www.symantec.com

This message (including any attachments) is intended only for the use of the individual or entity to which it is addressed and may contain information that is non-public, proprietary, privileged, confidential, and exempt from disclosure under applicable law or may constitute as attorney work product. If you are not the intended recipient, you are hereby notified that any use, dissemination, distribution, or copying of this communication is strictly prohibited. If you have received this communication in error, notify us immediately by telephone and (i) destroy this message if a facsimile or (ii) delete this message immediately if this is an electronic communication.

What's the issue?

Nothing really: https://security.googleblog.com/2018/03/distrust-of-symantec...

https://alwaysonssl.com/id-verify/%3Ch1%3ECool%20Stuff

https://alwaysonssl.com/id-verify/ReplaceMeWithARegexAtLeast

https://alwaysonssl.com/id-verify/%3Cstyle%3E%40keyframes%20...

Not a great sign when they have only a handful of pages and still manage to have super basic XSS issues.

Just signed up. Cert is valid for 12 months and is chained from DigiCert's CA -- same as their website

1. who's the root CA? the website itself seems to use digicert.

2. what's the validation length?

Looks like they're a DigiCert reseller - https://www.certcenter.com

How is this different from LetsEncrypt?

Whoa, interesting. Does this differ from LetsEncrypt?

Its backed by Comodo :D

I certainly don't like the complete lack of information on the webpage though...

Looks like DigiCert and not Comodo.

> "CertCenter is a Master Reseller for DigiCert Encryption Everywhere."

You are right; I mistook one of their blog posts about adding Comodo as a partner, but appears to be a separate product...not that it makes me feel any better

The 12 month validity - which means it's way more useful if you want to pin certificates in a mobile app...

this is huge. And a killer difference. This means you can bake these certificates into Docker images as well.

PSA: Don't do this. Secrets don't belong in docker images, they belong in proper secret management tools.

I get what you mean - i would say that not everyone has a devops team and is setting up a whole bunch of infrastructure. I would rather recommend a ssl certificate baked into a docker image (stored in a private registry) versus no https at all

even if you use a secrets management tool, there are very few (probably none) that can bootstrap a Letsencrypt api. So this new one makes that possible as well.

If you want something simple, how about just installing nginx on the host to forward-proxy your Docker container?

but how is that more secure or simpler than running a docker image ?

to setup the nginx on my host, i would still have to store the certificates somewhere right.

Docker is not what is making this thing complicated.

Using nginx and a let's encrypt client on the host, the certificates are only generated and kept inside the machine itself. That's safer than baking them into the Docker image, which will be copied around.

How so? You pin the public key part in the cert not the whole cert itself. The key you use (should) stay the same.

No wildcards it looks like

REST API is nice though

I wonder if this is related to Symantec's Encryption Everywhere program[1]?

[1] https://www.symantec.com/about/newsroom/press-releases/2016/...

can i trust this?

if you can't trust a CA, then it's already game over, since they can issue certificates for any domain they want without your interaction.

Sure, but I assume the question is whether you can trust this particular CA.

presumably they're from a trusted root, so you (and everyone else) already trust them

Certificate resellers can't issue a certificate without you allowing them (by doing domain verification with their root CA).

See: that certificate company who emailed a bunch of private keys recently. They were also a digicert reseller.

They were also a digicert reseller.

No, they (Trustico) were a Symantec reseller, and then switched to Comodo. "Although DigiCert took over Symantec's certificate issuance business, it doesn't count Trustico as a reseller."

https://arstechnica.com/information-technology/2018/03/23000...

TrustICO was also from a trusted root, and look what happened there (same with Comodo and their bad business dealings). Just because DigiCert trust them doesn't mean the company is trustworthy (in the human sense, not the PKI sense).

I assume what alexnewman meant was "can I trust that certificates issued by this entity will not be revoked in the near future due to incompetence of the CA", and not "can I trust websites which serve certificates signed by this CA".

https://news.ycombinator.com/item?id=16566165

I wouldn't.

A free and automated CA goes against exactly what a CA is supposed to be: someone you can trust. If you can't trust the CA, then you can't trust anything related to the CA. What's the point in having this, besides the convenience of importing their untrustworthy CA key and then using https without getting warnings? I would rather use http.

Trust to do what? What matters is whether they can be trusted not to misissue certificates. For Domain Validation certificates, this means only issuing a certificate for a domain if whoever holds the private key for that certificate also has technical control over that domain (there are other requirements but that's by far the most important one). This can easily be verified through automated means, so a CA automating the issuance of DV certs is no problem. There are other ways a CA can screw up, of course, but none of them is implied by automated issuance.

Once an unreliable CA gets "trusted" and its public key added to browser bundles, that's when they can pivot to allowing undetectable surveillance of traffic, by allowing access to private keys. Things like local DNS poisoning, etc, are all easy to do, and if you can create your own www.google.com certs temporarily, there's no limit to how much traffic you can acquire.

What are you talking about?

The root certificate for this CA is already baked into our browsers; otherwise, there would be no way for them to issue working certificates.

It’s actually much more difficult to issue a cert for a domain like “www.google.com”:

- Google uses Certificate Authority Authorization (CAA) which tells the internet that only Google is allowed to issue certificates for google.com

- Google uses HTTP Public Key Pinning (HPKP) headers that shows the hash of the public key that will be trusted; a cert issued for google.com by a rogue CA can’t have the same public key and thus won’t be trusted.

- Google created the idea of Certificate Transparency (https://www.certificate-transparency.org); almost all certificates are logged publicly in cryptographically signed databases (blockchains actually) which anyone can examine. It would be obvious in a few minutes that a certificate were issued for google.com, assuming it could be done. Google, Apple, Mozilla, etc. won’t trust certificates that aren’t in CT logs.

Here’s the info on Google’s latest certificate issued yesterday: https://crt.sh/?id=354538345

The best part: everyone has access to these tools and standards, not just big companies. My free certificates from Lets Encrypt also go in Certificate Transparency logs, just like Google’s.

Reply on news.ycombinator.com