So, I spent a few weeks building an in house solution that automates the whole process of provisioning and renewing SSL certs for our users. It involves Let's Encrypt and has been working great so far!
Last week I thought of offering this as a SaaS product. With the help of my friend, I coded an app where customers can add their domains in a few steps. It's live at https://autossl.co. Once a domain is added to our system, we generate a CNAME record for that domain. When the domain is accessed for the first time, we generate an SSL cert on demand through Let's Encrypt and renew it every 3 months. I also expose APIs to add domains to our system. So, if you are a SaaS company offering custom domains to your customers, you can completely automate SSL issuance in an easy and cost effective way.
I think it has got some potential. What do you think?
Additionally, Let's Encrypt is a partner with cPanel's AutoSSL, so even more confusion may arise out of that.
For example: https://www.google.com/search?q=autossl
* Will AutoSSL also provide a way for the customer to login and provide them instructions on how they can setup the domain on their side?
* Some of our customers had CAA records preventing LE from working. This is about informing the customer that this record exists and what the possible alternatives are.
* This was mentioned elsewhere but AutoSSL is a cPanel feature. So, I would consider rebranding.
* What are the proxying limitations? Does it support Websockets? How much load can it handle?
> Will AutoSSL also provide a way for the customer to login and provide them instructions on how they can set up the domain on their side?
Yes, I expose two APIs - add and delete. When your customer adds a domain, you can hit our API to whitelist it. The API responds back with CNAME instructions. Your app just needs to pick it up and display it to the users.
> What are the proxying limitations? Does it support Websockets? How much load can it handle?
I have 5 servers right now that handle TLS and fetch content from the origin. I just did a load testing with about 20K requests per minute, and it did fine. Will do more tests as I move forward. But before doing anything just wanted to know if anyone is actually going to use the product. :D
- If I were a service provider I wouldn't wanna be dependent on a third party service for something as basic as TLS certs. I'm not an expert in your domain but to me this looks like something that could happily coexist as a service with a self-hostable (possibly FOSS) option (since the convenience advantage of a service is still there).
- Security: Can you read my customers' traffic? (A self-hosted option could also help with this for high-sensitivity use cases).
- What about rate limits? My customers could be in a situation where the standard LE rate limits are already pretty tight. Can I (and subsequently my customers) see/manage how much quota AutoSSL is using?
All that networking hardware terminating SSL between external and internal traffic can also read all a company's traffic, but I guess Cisco or some chinese manufacturer is more trustworthy...right?
... not affliated with the OP at all.
Some of the security groups at major fort-500 companies I've worked at were run by people that could powerpoint well, graduated from surfing suitcase schools, and showed no awareness of even mass media security failings (heartbleed).
You'd think these divisions would have extremely smart PhD level security folks that could follow the basics of what the attacks used, but they were all just people that did vendor RFPs, made dumb policies (8 char max password, only use approved versions of software that were already out of date and had known vulnerabilities, internal password change site wouldn't show in Chrome because the cipher suite was hopelessly compromised)
Different idea though: Shouldn't GDPR data processing agreements cover these sorts of cases?
Yes, anything that (re)terminates TLS will be able to - including this - and there is no way around it short of hosting it on-prem.
Marketing it as end-to-end security the way the author is doing is ... wrong.
Yes they can.
>A self-hosted option
Aren't those enough options?
It takes a file with a list of domains to check and you can write your own hooks to handle the DNS management and certificate deployment however you want.
And tell me what this service can do what resty-auto-ssl can't. And there are a lot of different implementations for every language because it is easy.
- Branding as SSL is confusing, SSL is dead. TLS is the replacement.
- SaaSes can just front their apps with https://caddyserver.com/v1/docs/automatic-https
- Writeup of a SaaS using Caddy for this instead: https://ohdear.app/blog/how-we-used-caddy-and-laravels-subdo...
So this is routing plain text http for most of the connection and at the same time giving the managed edge location direct access to the traffic and a valid tls cert for the domain? Isn't that mostly snake oil then, as the secure connection never originates from the target service?
It cannot be secure end-to-end, as your edge location is quite literally performing a MITM. That aside:
How are you validating the TLS cert that the origin presents?
Going by the info on your website, the possibilities are as follows:
Scenario 1: The SAAS provider presents a TLS cert not valid for customer-domain.com when accessed as customer-domain.com
Scenario 2: The SAAS provider presents a TLS cert valid for customer.saasprovider.com when accessed as customer.saasprovider.com
Assuming scenario 1, you would need to validate the certificate out-of-band as the traditional trust chain does not validate for the given domain.
Assuming scenario 2, you would need to rewrite the URLs from customer.saasprovider.com to customer-domain.com to prevent the users from following generated resource URLs to the origin domain.
Or am i missing something?
No it isn't. You are doing a MITM.
the "end"s are the _browser_ and the _origin_, and if there isn't a single secure channel that goes all the way between them, that's not "end to end".
I mean take the "piecewise" argument to its natural conclusion.
If the reason it's okay for you to be in the middle is that you're going to ensure that your request to origin is also encrypted, why should you be the only party in between that can decrypt the contents of the connection?
Why not let the ISP also decrypt the contents? What about the layer 3 interconnect providers? How about your cable modem and your router (they're _probably_ patched 'enough' that it's safe to let them see your plaintext).
I'm harping because misuse of the term "end to end" is _actually dangerous_ to real people.
All of this is to say nothing of the fact that when you allow "middle-boxes", the client no longer has control over the ciphers that are used for the end-to-end connection, so they lose control over perfect forward secrecy.
> but this is what cloudflare does!
yes, and it already caused one of the worst breaches in the short history of the internet https://news.ycombinator.com/item?id=13718752
Seems like yet another betrayal of the end-to-end principle (as is this product for that matter)
Is it too late to make this switch? Names are sort of like that in China.
From the home page, I click the "Features" link, then press the back button on my browser. It returns a blank white page with the text: "An unexpected error has occurred." No other links seem to do this (probably has something to do with the hash url).
I'm on Windows 10 using the latest Chrome.
EDIT: After reading the comment you quoted (https://news.ycombinator.com/item?id=21527011), this doesn't seem to be a personal project after all...