
AlwaysOnSSL – A free and automated CA - tvvocold
https://alwaysonssl.com/
======
trothamel
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.

~~~
DyslexicAtheist
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://www.certcenter.com/company/terms)

²
[https://portal.etsi.org/tbsitemap/esi/trustserviceproviders....](https://portal.etsi.org/tbsitemap/esi/trustserviceproviders.aspx)

³
[http://www.webtrust.org/item64428.aspx](http://www.webtrust.org/item64428.aspx)

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

------
packetized
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%...](https://alwaysonssl.com/id-
verify/%3Ch1%3E%27%27%3B%21--%22%3CSCRIPT%3Ealert\(%22lol%20what%22\);%3C/SCRIPT%3E%3D%26%7B%28%29%7D)

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

~~~
lol768
Whitelisting entire CDNs like that is incredibly dangerous, see
[https://github.com/cure53/XSSChallengeWiki/wiki/H5SC-
Minicha...](https://github.com/cure53/XSSChallengeWiki/wiki/H5SC-
Minichallenge-3:-%22Sh*t,-it%27s-CSP!%22)

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

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

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

------
jensenbox
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...](https://alwaysonssl.com/id-
verify/GX5aT6H2vG8s-Td2CLOBBEREDCLOBBEREDRGnhhU_brYg7Lva-GPu2weViJk)

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.

~~~
testingca
[https://alwaysonssl.com/id-
verify/%3Ch1%3ECool%20Stuff](https://alwaysonssl.com/id-
verify/%3Ch1%3ECool%20Stuff)

~~~
jensenbox
[https://alwaysonssl.com/id-
verify/ReplaceMeWithARegexAtLeast](https://alwaysonssl.com/id-
verify/ReplaceMeWithARegexAtLeast)

~~~
Earwig
[https://alwaysonssl.com/id-
verify/%3Cstyle%3E%40keyframes%20...](https://alwaysonssl.com/id-
verify/%3Cstyle%3E%40keyframes%20blinker%7B50%25%7Bopacity%3A0%3B%7D%7D%3C/style%3E%3Ch1%20style%3D%22animation%3Ablinker%201s%20linear%20infinite%3B%22%3ECross-
site%20scripter%3F%20I%20hardly%20know%20her%21)

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

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

2\. what's the validation length?

~~~
lessclue
Looks like they're a DigiCert reseller -
[https://www.certcenter.com](https://www.certcenter.com)

------
tharri
How is this different from LetsEncrypt?

------
lessclue
Whoa, interesting. Does this differ from LetsEncrypt?

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

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

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

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

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

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

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

------
ENGNR
No wildcards it looks like

REST API is nice though

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

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

------
alexnewman
can i trust this?

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

~~~
michaelmior
Sure, but I assume the question is whether you can trust _this_ particular CA.

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

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

~~~
icebraining
_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...](https://arstechnica.com/information-
technology/2018/03/23000-https-certificates-axed-after-ceo-e-mails-private-
keys/)

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

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

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

~~~
alwillis
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);](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](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.

