And all because people like YOU donated :)
Thanks :)
btw if you want to donate too, here is the link: https://supporters.eff.org/donate
Launching in 2015: A Certificate Authority to Encrypt the Entire Web
241–250 of 476 posts
Re: Launching in 2015: A Certificate Authority to Encrypt the Entire Web
#242Earlier quoted context omitted.
Four things: (1) You can do the attack you describe today with existing CAs that are issuing DV certs because posting a file on the web server is an existing DV validation method that's in routine use. (2) There is another validation method we've developed called dvsni which is stronger in some respects (but yes, it still trusts DNS). (3) We're expecting to do multipath testing of the proof of site ownership to make…
agree completely and it's worth noting that i don't have a solution to the issues i mentioned, either. leveraging other (potentially-insecure) paths to establish trust might help further enhance confidence in authenticity; e.g. verification using something like the broad-based strategy of moxie's perspectives (except via plaintext) or maybe through additional verification of plaintext on the site as fetched via tor o…
Akamai published a blog post about their role: https://blogs.akamai.com/2014/11/lets-encrypt-boosts-push-fr...
Re: Launching in 2015: A Certificate Authority to Encrypt the Entire Web
#243The EFF has a bad track record in this area. The last time they tried something to identify web sites, it was TRUSTe, a nonprofit set up by the EFF and headed by EFF's director. Then TRUSTe was spun off as a for-profit private company, reduced their standards, stopped publishing enforcement actions, and became a scam operation. The Federal Trade Commission just fined them: "TRUSTe Settles FTC Charges it Deceived Cons…
> Anyone with access to the connection can tell what site you're talking to.
HTTPS encrypts the URL paths you access [1]. Would you rather an adversary knew which IPs you visited, or the IPs plus the URLs?
[1] http://stackoverflow.com/questions/499591/are-https-urls-enc...
Re: Launching in 2015: A Certificate Authority to Encrypt the Entire Web
#244Earlier quoted context omitted.
Self-signed certificates are still better than http plain text. I understand not showing the padlock icon for self-signed certificates, I don't understand why you would warn people away from them when the worst case is that they are just as unsafe as when they use plain http. IMHO this browser behavior is completely nonsensical.
How would a browser know that the the self-signed certificate that was just presented for www.mybank.com is intended to be self-signed (show no error, but also show no padlock) or whether it's the result of a MITM attack because www.mybank.com is supposed to present a properly signed certificate (show error)? How would you inform people going to www.mybank.com which is presenting a self-signed cert in a way that a) t…
You would have to simply install the certificate for the CA that signed the certificate. Self-signed just means that YOU are the CA.
Re: Launching in 2015: A Certificate Authority to Encrypt the Entire Web
#245Can wait until summer 2015 for a free cert? CloudFlare offers Universal SSL: https://www.cloudflare.com/ssl
Those free certs will encrypt from the browser to CloudFlare's CDN. You still need to do something to encrypt from CloudFlare to the publishing webserver. Self-signing can work for that hop, though Let's Encrypt may wind up being smoother for sys admins.
We've been working with CloudFlare to drive HTTPS adoption, and plan to work with them further on integration.
Re: Launching in 2015: A Certificate Authority to Encrypt the Entire Web
#246This 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…
> 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…
"Treating this as a grave error IMHO is right because by accepting the connection over SSL, you state that the conversation between the user agent and the server is meant to be private."
This is misguided thinking, pure and simple. Because of this line of thinking, your everyday webmaster has been convinced that encrypting data on a regular basis is more trouble than it's worth and allowed NSA (or the Chinese or the Iranian or what have you) authorities to simply put in a tap to slurp the entire internet without even going through the trouble of targeting and impersonating. Basically, this is the thinking that has enabled dragnet surveillance of the internet with such ease.
Re: Launching in 2015: A Certificate Authority to Encrypt the Entire Web
#247This 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…
> 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
Re: Launching in 2015: A Certificate Authority to Encrypt the Entire Web
#248It 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…
Hm? The overhead reduction is on the server. Verification IIRC is somewhat slower.
There are CAs that issue them, uh... someone managed to get one issued during the TLS WG meeting at IETF last week. I'd have to listen to the audio to find out what CA they used.
Re: Launching in 2015: A Certificate Authority to Encrypt the Entire Web
#249This 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 have some certificates through RapidSSL, and when they send me reminders to renew, the e-mails come with this warning: "Your certificate is due to expire. If your certificate expires, your site will no longer be encrypted." Just blatantly false.
They might as well say something even more ominous: "If your certificate expires, your site will no longer be accessible."
Of course, we know that's not true either, but try explaining to your visitors how to bypass the security warning (newer browsers sure don't make it obvious, even if you know to look for it).
Re: Launching in 2015: A Certificate Authority to Encrypt the Entire Web
#250Earlier quoted context omitted.
I doubt the actual CA has been setup either. They're setting up their own root while cross signing from IdenTrust, that's not a one day activity. Auditors have to be present, software has to be designed and tested, etc.
It's true that this shouldn't be done in a day, but it's trivial compared to building a command line tool that automatically configures HTTP servers and designing an open protocol that issues and renews certificates. This is especially true if one of your partners is a CA. --- Let me be clear here: I'm not complaining that I don't get my free cake now. I do think however that most people at the EFF and Mozilla would…
:-) It's technically easier but organizationally more difficult and time consuming.