How does this compare to StartSSL?
maybe they won't try to extort you if you require a revocation?
(StartSSL do even for paying customers... stay away)
Launching in 2015: A Certificate Authority to Encrypt the Entire Web
281–290 of 476 posts
Re: Launching in 2015: A Certificate Authority to Encrypt the Entire Web
#282Earlier quoted context omitted.
> A self signed certificate warning means "Warning! The admin on the site you're connecting to wants this conversation to be private but it hasn't been proven that he has 200 bucks for us to say he's cool" no. It means "even though this connection is encrypted, there is no way to tell you whether you are currently talking to that site or to NSA which is forwarding all of your traffic to the site you're on". Treating…
So this is where we stand: Encrypted (Certified) COOL GREEN Encrypted (Self-Signed) EVIL RED Unencrypted NOTHING / NEUTRAL CHROME I think there's a pretty blatant antipattern here, and I'm not talking about colourblind-proofing the browser chrome.
> Encrypted (Certified) COOL GREEN
I think we can agree that this case is correct. If you have a properly vetted cert, more power to you. The browser should tell your users that you do own this domain.
> Encrypted (Self-Signed) EVIL RED
Not quite. Your user does have the ability to permanently trust this certificate. However, if I am trying to access gmail.com over HTTPS, I better not get this error. Otherwise, I know for a fact someone is messing with me.
> Unencrypted NOTHING / NEUTRAL CHROME
This case should be eliminated. We need to stop publishing stuff over HTTP. Period. The browsers should start fast tracking dropping support for HTTP altogether so we don't even have to think about this case.
Now the solution for case #2 is that every time you buy a domain, your registrar should issue you a wildcard cert for that domain. Moreover, you should be able to use that private key + cert to sign additional certs for individual subdomains. That way we can eliminate all the CA's. We would essentially use the same infrastructure that already supports domain name registration and DNS instead of funding a completely parallel, yet deeply flawed CA industry. As a bonus, this way only your registrar and you may issue certs for your domain.
This is all castles in the sky, but IMO that's the correct solution.
Re: Launching in 2015: A Certificate Authority to Encrypt the Entire Web
#283It would be nice to have support for ECDSA certificates. I've not found a CA yet who'll provide one of these, despite the fact that many clients to already support them. Unfortunately, after a brief look through client.py I can't see any support for this. Is there any good way of filing an RFE or contributing a patch? ECDSA certs are much cheaper to decrypt, and there's still some places (especially mobile) where TLS…
[deleted]
Re: Launching in 2015: A Certificate Authority to Encrypt the Entire Web
#284Earlier quoted context omitted.
What kind of abuse where you thinking about? If the domain is hijacked, you simply repossess the domain and request a new certificate and the old one is revoked.
As in, revoking a cert for a known C&C box, or a confirmed spammer, confirmed box serving an exploitkit, confirmed phishing domain (such as my-apple-ikloud-verify.foo) Basically, my assumption is they won't want to be providing certs to known bad actors. So I'm curious who is going to own the abuse handling for the CA.
Those issues are in theory handled by taking down the people who commits it, and in practice by taking down the domain names, since those normally has been registered using false credentials. One can hope/assume that this system will automatically revoke domains that expire or get removed.
Re: Launching in 2015: A Certificate Authority to Encrypt the Entire Web
#285Here's my current issue with moving to TLS: library support.
I do a lot of custom stuff and want to run my own server. I can set up and run the server in maybe 50-100 lines of code, and it works great.
I know, I should conform and use Apache/nginx/OpenSSL like everyone else. Because they're so much more secure, right? By using professional code like the aforementioned, you won't get exposed to exploits like Heartbleed, Shellshock, etc.
But me, being the stubborn one I am, I want to just code up a site. I can open up a socket, parse a few text lines, and voila. Web server. Now I want to add TLS and what are my options?
OpenSSL, crazy API, issues like Heartbleed.
libtls from LibreSSL, amazing API, not packaged for anything but OpenBSD yet. Little to no real world testing.
Mozilla NSS or GnuTLS, awful APIs, everyone seems to recommend against them.
Obscure software I've never heard of: PolarSSL, MatrixSSL. May be good, but I'm uneasy with it since I don't know anything about them. And I have to hope they play nicely with all my environments (Clang on OS X, Visual C++ on Windows, GCC on Linux and BSD) and package managers.
Write my own. Hahah. Hahahahahahahahah. Yeah. All I have to do is implement AES, Camellia, DES, RC4, RC5, Triple DES, XTEA, Blowfish, MD5, MD2, MD4, SHA-1, SHA-2, RSA, Diffie-Hellman key exchange, Elliptic curve cryptography (ECC), Elliptic curve Diffie–Hellman (ECDH), Elliptic Curve DSA (ECDSA); and all with absolutely no errors (and this is critical!), and I'm good to go!
I'm not saying encryption should be a breeze, but come on. I want this in and available anywhere. I want to be able to ask for socket(AF_INET, SOCK_STREAMTLS, 0), call setsockcert(certdata, certsize) and be ready to go.
Everything we do in computer science is always about raising the bar in terms of complexity. Writing software requires larger and larger teams, and increasingly there's the attitude that "you can't possibly do that yourself, so don't even try." It's in writing operating systems, writing device drivers, writing web browsers, writing crypto software, etc.
I didn't get into programming to glue other people's code together. I want to learn how things work and write them myself. For once in this world, I'd love it if we could work on reducing complexity instead of adding to it.
Re: Launching in 2015: A Certificate Authority to Encrypt the Entire Web
#286I couldn't be happier about the news, the EFF and Mozilla always had a special place in my heart. However, the fact that we have to wait for our free certificates until the accompanying command line tool is ready for prime time seems unnecessary. Another thing I'm interested in is whether they provide advanced features like wildcard certificates. This is usually the kind of thing CA's charge somewhat significant amou…
The thing that's causing the delay is not the client software development, it's the need to create the CA infrastructure and then perform a WebTrust audit. If we were ready on the CA side to begin issuing certificates today, we would be issuing them today.
I think I may have misunderstood all of you. Is the audit process itself really that time consuming? I can imagine the amounts of bureaucracy involved, but I can't image this takes much longer than, say, a month or so. Most of the time is probably spent waiting for someone or something, right? I mean we're talking about very capable people here who have done this kind of thing before.
Re: Launching in 2015: A Certificate Authority to Encrypt the Entire Web
#287Earlier quoted context omitted.
What kind of abuse where you thinking about? If the domain is hijacked, you simply repossess the domain and request a new certificate and the old one is revoked.
As in, revoking a cert for a known C&C box, or a confirmed spammer, confirmed box serving an exploitkit, confirmed phishing domain (such as my-apple-ikloud-verify.foo) Basically, my assumption is they won't want to be providing certs to known bad actors. So I'm curious who is going to own the abuse handling for the CA.
No reason bad actors can't be encrypted on the wire just like all the other actors.
Re: Launching in 2015: A Certificate Authority to Encrypt the Entire Web
#288Earlier quoted context omitted.
You speak as if the power of NSLs has a functional limit - it doesn't, which is what makes the entire concept so dangerous. There's nothing stopping the requirements from being "mint us a certificate according to these specs" and additionally "okay, now pin this certificate in your browser".
You might want to read up on what an NSL actually is, since you and the GP are clearly very confused.
It's a letter, issued by an occult kangaroo court, that coup d'etat forces hold in hand while demanding the keys to the kingdom - a demand that can't be challenged in a legitimate court of law.
Re: Launching in 2015: A Certificate Authority to Encrypt the Entire Web
#289This certificate industry has been such a racket. It's not even tacit that there are two completely separate issues that certificates and encryption solve. They get conflated and non technical users rightly get confused about which thing is trying to solve a problem they aren't sure why they have. The certificate authorities are quite in love that the self-signed certificate errors are turning redder, bolder, and big…
I'm not entirely sure I understand your point, so if I misunderstood you please correct me. First, TLS has three principles that, if you lose one, it becomes essentially uselsss: 1) Authentication - you're talking to the right server 2) Encryption - nobody saw what was sent 3) Verification - nothing was modified in transit Without authentication, you essentially are not protected against anything. Any router, any gov…
Encryption without verification is not useless; it protects against snooping.
Re: Launching in 2015: A Certificate Authority to Encrypt the Entire Web
#290Earlier quoted context omitted.
but as user I can understand that an http site is insecure, while a self signed certificate might lead me into a false sense of security.
That's the proffered reasoning as we all know. But the actual outcome (to quote rufb from this comment https://news.ycombinator.com/item?id=8625739 ) Encrypted (Certified) COOL GREEN Encrypted (Self-Signed) EVIL RED Unencrypted NOTHING / NEUTRAL CHROME Tell me how the logic works here (for an average user).
Not considering the many holes, cyphersuites, running TLS 1.3+ etc.
( http://wingolog.org/archives/2014/10/17/ffs-ssl )
...it should probably look like this:
Safe against active attacks:
Encrypted (Certified) COOL GREEN
Encrypted (Self-Signed) SCARY ORANGE
Unencrypted EVIL RED