Sslip.io: A Valid SSL Certificate for Every IP Address | Hacker News Reader

Sslip.io: A Valid SSL Certificate for Every IP Address

blog.pivotal.io

167 pointsarianvanp112 comments

So, these guys bought a COMODO wildcard certificate and then stuck it (public and PRIVATE parts) on Github for anyone to download.

Wonder how long before COMODO revokes this cert?

If you have a test domain you can stick it on CloudFlare and get a certificate for free without the private part becoming public.

That it's nor revoked yet doesn't reflect well on COMODO at all, not that it's the first thing that doesn't...

Came here to say the same thing.

Doesn't the CA forum baseline require a revocation if the private key is published?

https://cabforum.org/wp-content/uploads/CAB-Forum-BR-1.3.0.p... on page 18:

    The CA SHALL revoke a Certificate within 24 hours 
    if one or more of the following occurs: 
    (...)
    3. The CA obtains evidence that the Subscriber’s 
    Private Key corresponding to the Public Key in the
    Certificate suffered a Key Compromise or no longer
    complies with the requirements of Appendix A;

Hm, how is that compatible with Startcom's policy of charging for revocation?

Good question. Maybe you can skip the fee by posting your private key to pastebin and send them the link? :P Might not leave you with an account in good standing with them though ;)

That has been tried before: https://web.archive.org/web/20140412085458/https://revokame....

Hah. So sslip.io should went with Startcom instead of Comodo.

Mozilla should probably add 'charging for revocation' to their list of problematic practices (required to be included in Firefox). Not that revocating compromised certificates isn't already required, but just that some behavior by poor CAs needs to be explicitly pointed out: https://wiki.mozilla.org/CA:Problematic_Practices

What? Revoking expired certificate is not required, and would be a completely useless thing to do, bloating CRLs for no gain whatsoever.

Sorry, my bad. I wrote 'revoking expired certificates' rather than 'revoking compromised certificates'. Now fixed.

It isn't.

I was actually looking at the comodo website to figure out if I can submit revokation on my own (we've got the key after all...). Gave up after looking at 20+ pages. Apart from a login site for email cert revocation, I can't find any reasonable contact.

Comodo website is not that good apparently.

Edit: in the document posted by brohee: (about authentication for certs revocation) "OR the Subscriber must be able to send an S/MIME email signed with the private key associated with the Certificate". That's doable :)

sslabuse@comodo.com it is

4.9.2 Who can Request Revocation A Subscriber or another appropriately authorized party can request revocation of a Certificate. An authorized party includes an RA, regardless of whether on behalf of the Subscriber may request revocation through their account. Other parties may report suspected Private Key Compromise, Certificate misuse, or other types of fraud, compromise, misuse, inappropriate conduct, or any other matter related to Certificates, in the first instance, by email to sslabuse@comodo.com.

COMODO policy is compliant, they just didn't act on it yet

https://www.comodo.com/repository/Comodo_CA_CPS_4.1.4.pdf

4.9.1 Circumstances for Revocation Comodo may revoke a digital Certificate if any of the following occur:

A personal identification number, Private Key or password has, or is likely to become known to someone not authorized to use it, or is being or is likely to be used in an unauthorized way

Well, if the buyer of the certificate authorizes everybody to use the private key, technically it's not a "use [...] in an unauthorized way".

It may be unauthorized per Comodo's TOS.

Yes, but the CloudFlare/server leg is unencrypted.

We give customers a certificate signed against our CA to secure the CloudFlare to origin server connection.

You do? Last I checked, I just saw that you had the option to put a self-signed cert on your own server, but no way to tell CloudFlare to validate it (e.g.: I couldn't upload my public cert to CF and say "this is what you should expect"). Alternatively, I could buy my own valid cert and put it on the server. Is the option to get a valid signed cert from CF new?

https://blog.cloudflare.com/universal-ssl-encryption-all-the...

Did this actually come out?

I've never seen the option in the panel for this, and as far as I know only a handful of users got accepted into the 'beta'.

Hmm, I use your TLS cert but I didn't see the CA-signed one I can use. I'll read the blog post below, thanks.

I use a self signed cert between CloudFlare and my server, I actually couldn't get it to work without doing that, for some reason.

Cloudflare has a few options you can choose from for cloudflare<=>origin connections. I've tried them all out and they've worked as advertised as far as I could tell:

I set up Cloudflare with their "Strict" SSL option, which requires that my origin servers use a valid TLS certificate. I paid the CA toll to get a cert for my site, and I use that cert to serve connections from Cloudflare's servers.

They also have a "Full" option, which allows you to use a self-signed cert (with no validation -- you might be able to require validation of self-signed certs if you're on a paid plan) on your origin servers, which is slightly more secure than the "Flexible" option, which uses HTTP (with no encryption) when connecting to the origin server, even though it then serves the content to end users over HTTPS with their own (valid) cert.

Yeah this should be revoked. Mozilla's CA acceptance programs mandate that the CA revokes the cert if the key gets compromised, and I presume others do too.

> If you have a test domain you can stick it on CloudFlare and get a certificate for free without the private part becoming public.

It all comes down to the fact that CA's don't want you to sign your own certificates, even when it's one of your subdomains unless you pay the big bucks. Best thing to do it still to create your own CA and sign certs for these kinds of things since it's meant for testing and development anyway. It's not that hard, anyone can use some command line can do it.

I'm surprised there's no "CA-tool-as-a-service" where the CA provides an API (and maybe a CLI tool that uses that API) allowing you to automatically request-and-generate certs from their CA server provided it's for a subdomain of a domain you have on your account.

Typical way to tackle sub-domains would be to issue a wildcard certificate.

This would be for subdomains with their own "sovereignty"; e.g. Tumblr or Wordpress blogs, where the subdomain "owner" could conceivably want to issue their own subdomains, or, heaven forbid, do client-cert signing for their subdomain.

That's essentially what Let's Encrypt aims to be: https://letsencrypt.org/

Check out OpenStack's Anchor project, it is exactly this.

If the people behind the post used anchor, then the issues mentioned here would be absolved.

Nearly every CA has an API already, you can add automated Domain validation yourself over a weekend.

Have a look at the "certificate" section of Gandi's API https://github.com/Gandi/gandi.cli/blob/master/gandicli.man....

And check out SSLmate https://sslmate.com/

Already happened....

Secure Connection Failed An error occurred during a connection to 52-0-56-137.sslip.io.

Peer's Certificate has been revoked.

For anyone else wondering: run Firefox on https://52-0-56-137.sslip.io/

It'll be gone in Chrome when the next CRLSet is fetched: https://scotthelme.co.uk/certificate-revocation-google-chrom...

SSL Labs test confirms that it has been revoked: https://www.ssllabs.com/ssltest/analyze.html?d=52-0-56-137.s...

I contacted one of the founders. The will regroup and solve it hopefully https://twitter.com/briancunnie/status/641258677429628928

Revoked already!

Why? If I own a domain, then declare that "administrators of this domain include: everyone.", then how is the cert invalidly issued?

BTW we love CloudFlare. But the DNS limitations (no wildcards for SSL without $$$$/month, only top-level subdomains allowed) really hurt for developing things. The wildcard bit I understand (valuable service), the multi-level hostnames I don't get; sounds like some technical issue? I know you just get a wildcard for the root, but even paid I've been told there's no workaround. So I can't do [stuff].test.example.com.

    *.example.com won't match foo.bar.example.com.

That's a technical limitation of the way name matching works (similar to DNS); not a CloudFlare restriction.

Our free Universal SSL certificate includes a wildcard (so if you sign up example.com you get *.example.com).

Right, but even in paid plans, there's no ability to get further subdomains. Just pointing that out and wondering why. Technical issue that isn't worth the effort?

Annoyingly, TLS wildcards have very a different meaning to DNS wildcards.

DNS wildcards only work when * is the leftmost label of a domain name, so

    *.example.com is a wildcard
    foo.*.example.com is not a wildcard
    *bar.example.com is not a wildcard

A DNS wildcard matches any non-zero number of labels, so

    *.example.com
    foo.example.com matches
    foo.bar.example.com matches
    example.com does not match

RFC 4592 describes DNS wildcards.

Unlike the DNS, the * in a TLS certificate can only match one label, so

    *.example.com
    foo.example.com matches
    foo.bar.example.com does NOT match
    example.com does not match

RFC 2818 also allows the * to appear within a domain name, not just as the leftmost label, and wildcards work even when they are part of a label. One of its examples says

    f*.com
    foo.com matches
    bar.com does not match

But nowadays sub-label wildcards like this are not supported.

> RAM is not stressed: of the 1015MiB of RAM, 182MiB are free, and only 6MiB of swap is used. We typically don't worry about RAM on Linux systems until the swap space used exceeds twice the physical RAM

That's a bad metric. The question is rarely "does this machine use too much swap". The problem comes when performance is degraded because pages that were evicted out to disk are now needed again, and those processes wait for I/O. swapin and swapout are the relevant figures.

edit: (If you're only using 6M of swap, it doesn't really matter, of course. But if a system uses any substantial amount of swap, you want to check rate, not quantity.)

Yes, that is quite a strange recommendation and the recommendation of "until the swap space used exceeds twice the physical RAM" is really crazy. The best recommendation for production servers is to disable your swap/page file completely then just let your entire system crash on OOM.

Often times it's better to have a dead system (you do have HA and auto-failover, right?) than to let difficult-to-track-down "slowness" into real time systems.

If your failover doesn't take extreme slowdowns into account, you've still screwed up.

It's more complicated than just turning off swap. Even without swap, when you run extremely low on memory the page cache will be squeezed to nothing and you'll thrash. And I don't think there's a way to set a minimum page cache on Linux.

So in other words, I would not rely on the OOM killer ever kicking in.

In a situation with more memory use over time a small swap can act as a canary, letting you know you're nearing a performance drop, while a swapless server could suddenly hit a molasses wall without dying.

Thrashing the page cache is typically much less horrible than swap thrashing, so swap off is still an improvement.

If you want a canary, why not just directly monitor the page cache size?

I suppose it depends how big your binaries are, but once those are getting culled from memory things are not pretty.

Keep in mind that if your swap is not huge, it will very often fill will cold data and you won't have swap thrashing despite running out of memory.

Good point about measuring the page cache directly.

Ah yes. We can agree that both small swap and no swap are superior to the "2x RAM" nonsense that still pops up as a recommendation though.

It's always a fun time when a process eats all your memory, your machine crashes, and failover launches it on another identical machine (only to repeat the process)

The recommendation (swap == 2 x RAM) was more common in the nineties when RAM was much more expensive. It was a reflection that the resident set size (RSS) of a process is often a fraction of its Virtual Memory footprint (often an order of magnitude smaller), so a process could run effectively even with most of its data swapped out to disk.

There was a fair amount of interesting engineering to make swap effective.. For example, for the code (text) segment, which was read-only, you'd use the file itself (e.g. a.out) as the swap for the text (code) portion, and if you'd try to `rm a.out` while it was running, you'd get a "text file busy error".

You're absolutely correct. Time permitting, I may go back and adjust my description.

You're absolutely correct--amount of swap isn't as good a metric as how much it's stressed (how much is being swapped in/swapped out). Time permitting I may update the blog, and with your permission use your comment)

While I despise the SSL cartel, there are many problems with this attempt at a solution.

Let's Encrypt began testing their free SSL certificates this week and will formally launch November 16th (two months from now)

https://letsencrypt.org/2015/08/07/updated-lets-encrypt-laun...

However they have no plans for wildcards and you have to renew every 90 days (automation possible).

They also do not have their intermediate certificate working yet (but will have to by November).

But if you do not need wildcards, the StartSSL free certificate has been an option for a long time:

http://www.startssl.com/?app=33

(startssl works in all browsers and has a 1 year renewal)

> But if you do not need wildcards, the StartSSL free certificate has been an option for a long time

And if you need a wildcard cert, startssl will give you any number of those for just 50$.

gee how benevolent of them

while I in general also disagree with the whole CA thing one has to admit that running a CA is not for free. That setting up the auditing, buying a HSM, running the interfaces and so on. And last but not least running the CRL/OCSP infrastructure. From my point of view the main part you pay a good CA for is that they run the OCSP service. Though with OCSP stapling that burden is a bit relaxed.

startssl covers the cost of their labor, not the cost of a 'license' to use the certificate. Their cost is validating your identity, which is a one time thing. They call you, ask a few questions and that's it. 10 minutes of their and your time. After that you are entitled to create as many certificates as you want. There's one caveat: the validation is only for one year, you have to renew it when your certificates are about to expire. Even if you have just one domain, it's cheaper than the alternatives. If you have multiple domains, startssl is much cheaper.

Actually it is $60 now - and the signup process for wildcards requires heavy duty validation - IDs, passports, corporation documents and other things are sometimes requested.

I wouldn't call that heavy duty. Sending them a scan of your passport or ID (which you already have somewhere on file...) is hardly too much to ask for. It didn't take me more than 10 minutes. And they'll even call you back to validate the information on a sunday! (which I think is impressive)

> But if you do not need wildcards, the StartSSL free certificate has been an option for a long time:

In fact, the free StartSSL Class 1 DV certificates are only available for non-commercial purposes. They DO enforce this, I have had a cert turned down by their "CertMaster" because they considered it part of a commercial operation.

That is why Let's Encrypt is doubly cool - it is not (at least, in any obvious way) motivated by $$.

WoSign issue free certs with up to 100 altnames, which is almost as good as a wildcard cert for many purposes, valid for up to 3 years. They also revoke for free.

They're the best option at the moment if, like me, you don't want want to put a penny in to the CA industry.

I was not aware of this option. However, it seems to be operating out of China. How does that affect security and availability in the long run?

Maybe availability but as long as you generate the private key part and paste your CSR on the website they can at worst revoke your certificate. So from a security perspective they're not worse then the others.

You already trust them. They're in all the major browser trust stores

It doesn't affect security, they're already in browsers' trust stores. It does affect availability, but only because (the last time I checked) WoSign's OCSP responders operated from China only. To address network latency issues with your users located far away, make sure you have OCSP stapling configured on your servers.

They lowered that to 10 lately. I was also surprised but I guess they pissed of others in the biz. Usually I see it limited to 40 by the comercial options.

On the server side you've to make sure you run a decent nginx/apache with OCSP stapling support. Their responders are slow.

Reminds me of GApps. First it was free (without support) for 50 users, then 10, now the free option is gone and they aren't even competitive if you just want quality personal or family webmail @yourdomain.com

If you're in the market for a certificate I'd jump on board now before it sails, and you're left 'stuck' with whatever automated hoop-jumping crapola Mozilla wheel out in 2 months.

From what I can see this uses the same public/private key for everyone using the service. So it would be easy to MITM any HTTPS connection using this if you're a network admin or hostile WiFi etc.

I don't think this is a problem for the intended audience - developers and test sites.

But there should perhaps be a clear warning somewhere about not using this in production.

EDIT: Turns out this is actually mentioned on the FAQ page of https://sslip.io/

I'm not suggesting that this makes it acceptable to use in production - but am I right in thinking that you'd be unable to MITM the connection if the server/client both support perfect forward secrecy?

Someone that intercepts the traffic act as a proxy and will just PFS with the client and the server.

Confidentiality should be ensured by PFS if the attacker is only sniffing. But so many scenarios where even an unsophisticaded attacker can do more that is is not worth thinking about.

That makes perfect sense - thanks.

It should have NOT SECURE written in big red letters - everyone has your private key, so there is no security at all.

It's very clearly stated on the project's website:

"sslip.io's primary purpose is to assist developers who need to test against valid SSL certs, not to safeguard content."

"Although there's no technical reason why you couldn't use the sslip.io SSL key and certificate for your commerce web, we strongly recommend against it: the key is publicly available; your traffic isn't secure."

I wonder what that scenario even is, where you need a trusted certificate and are also (for some reason?) unable to use the mechanisms widely available in environments (either OS or language/API) to trust a testing certificate.

This seems like a very silly service to operate, and as remarked by others, I guess the certificate will be revoked soon because the private key data is out there.

Mostly surprised that this wasn't obvious to a company like Pivotal from the first moment.

Because people seem to be missing it, here's a quote from the project website:

"sslip.io's primary purpose is to assist developers who need to test against valid SSL certs, not to safeguard content."

I don't think they're missing it. It's a bad idea and you can have your own valid certificate for free from many companies. Or for test, you can create your own cert in 2 lines of bash. (and add the ca to trusted store, so it's just as valid as this one)

For testing purposes you can also generate your certs valid only for a few hours/days, so you can be sure they never get used in production by accident. And with proper SAN entries.

Exactly - there's no need for a service like this when you can have self-signed certificates. Create a CA cert to distribute across your team, then use it to sign host, wildcard and SAN certs as needed. If you need to share your site with people who don't have your CA cert, it's time to get a real one.

In case it helps anyone, I wrote an openssl wrapper with a simple syntax to manage self-signed CAs: https://github.com/radiac/caman

That statement will totally prevent bad guys from using the trusted cert to scam...

I don't see how 'bad guys' are helped by having a working cert for 1-2-3-4.weirdacronym.io

Would you care to elaborate?

They could get a free cert other places, and even look like a real domain.

They would have gotten a valid certificate that couldn't be tied in anyway to their identity.

Coupled with e.g. a XSS vuln on a secured website, you could serve a nasty browser exploiting payload from a secure site, without any warning such as "this page is trying to load stuff from an unsecure site".

This in only one scenario, there are others. This really was pretty bad.

Free certs are tied to your identity?

More than having the IP?

SSL is not the place to enforce content restrictions.

Not even the paid certs that most people buy are tied to identity. Those only validate control of the domain (usually by having you whack some garbage into a DNS TXT record).

Yet another reason why the SSL PKI is a scam and a racket.

By proving control of the domain, there is a link between the certificate and the person asking for it thru the registrar. And thru the payment information to the registrar, you can usually get to someone.

It's a tenuous link, but a lot better than no link at all. At times enough for law enforcement to follow the tracks.

(edit since we reached maximum comment depth) Control of an IP address doesn't mean trackable ownership of it, you could use any machine your just compromised and instantly have a valid certificate for it. Delays in certificate issue add a thin layer of security, even if you gained unlegitimate control of a domain, the interval before asking and getting a certificate offers an opportunity for the intrusion to be detected and remediated.

Instant valid certificate for any IP address you happen to compromise is really quite bad.

Unless it's a free (sub)domain.

Why can't you do the same sort of tracking down if you have an IP?

Anything you pay for is ultimately traceable, at least by law enforcement, unless you're using a stolen credit card or a BTC tumbler. And even then, depending on the effort they're willing to invest, investigators could probably track the sale of the credit card number to you, notice that the BTC tumbler was pretty quiet when your money came out of it and there's only a couple of possible Coinbase accounts responsible, etc.

Paying for an SSL cert does make people a bit more accountable, but I'd argue that that's a bug rather than a feature.

Dylan, that was our thinking exactly--the URL would look unbelievably fake.

Once you look at it from the perspective of the crypto protecting the user instead of the content, it should be obvious why publishing the private key is not OK.

I've tried to find this info multiple times but what cert will work for:

domain.com

sub1.domain.com

sub2.sub1.domain.com

I'd love to buy one cert for my main domain and then be able to secure "infinite" depth of subs but every place I've contacted said that doesn't work yet they seem to have done just that...

There's a section in the article about how they use dashes instead of dots to separate octals in the IP. That way the wildcard cert covers those subdomains because they are only one level deep.

Ahh, I'm an idiot. Thank you for pointing that out to me. xip.io uses dots and so my brain just assumed dots on this one was well. I still would be very interested in finding a provider that did this or gave a reasonable number of domains on the cert. Though wildcard on subs is what I really want without having to buy one for each sub so I can do:

.server1.joshstrange.com

.server2.joshstrange.com

etc...

Providers can't do this, because browsers implement an RFC that doesn't allow multi-level wildcards.

Yeah, I've read this previously. It seems odd to me, I feel like I should be able to do this, I own the domain and I want to secure everything underneath it... sigh I guess I'll have to settle for a cert that allows for lots of domains under it and just have to create a different cert for each domain.

AFAIK, all major browsers follow RFC 6125 which says that only single-level wildcards are supported.

https://tools.ietf.org/html/rfc6125#section-6.4.3

https://bugzilla.mozilla.org/show_bug.cgi?id=646613

https://code.google.com/p/chromium/issues/detail?id=70517

Your best bet is probably to wait for Let's Encrypt to be generally available, so that you can automatically generate a separate certificate for every hostname.

https://en.wikipedia.org/wiki/SubjectAltName

That didnt take long...

Secure Connection Failed An error occurred during a connection to 52-0-56-137.sslip.io.

Peer's Certificate has been revoked.

How about an IP address for every person?

you mean IPv6?

I personally am very interested in IPv6, but the regular expression notation is more complex than IPv4: IPv4 has four decimals separated by dots; IPv6 has as many as 8 double-byte hex characters, sometimes as few as one (e.g. ::1). Plus, other than myself, I know few people who regularly use IPv6. It's not an intractable problem; I just wasn't ready to put the effort into it.

More like 1 IP for every atom in the universe.

I got curious... looks like we need IPv8 for that... estimates put it around 10^78, so 2^256 wont even do.

Nice hack, but:

What's preventing them from resolving YOUR-IP.sslip.io to a completely different IP address that delivers some malware to you?

EDIT: Changed "your users" to "you"

because you shouldn't have users on this

(See EDIT) Okay, so what's preventing them from develivering strange stuff to you, that claims to be your test site, but isn't?

Cert has been revoked

Further evidence that the SSL/TLS model of combining transport security and trust is broken.

sslip.io wildcard SSL certificate has been revoked!

http://i.imgur.com/IyYEJNm.png

Just a heads up, @BrianCunnie, you are dead. I'm not sure why. I don't see anything in the comment history to justify shadowbanning, maybe someone with more insight into how and why people are banned can elaborate. Sorry this is top-level, you can't directly reply to dead comments.

Thanks mini. I'm not sure why they banned me (I used a link in my first post?), but they let me create another account, and am now using that one.

Not banned; your new accounts set off a spam filter. Sorry. We marked them both legit and restored all the comments. Should be fixed now.

How about convincing the big browser vendors (e.g. through their bugtrackers) to finally accept CACerts without warning? Such a shame that.

As you can probably tell, Comodo revoked our certificate this morning.

For those interested in rolling your own, we recommend getting your own wildcard certificate and deploying your nameservers: https://github.com/cloudfoundry-community/xip-release#deploy...

In the interim, we plan to see if there's a way we can accomplish what we want without violating the terms of agreement.

Thanks for the interest,

Reply on news.ycombinator.com