I don't want to be a full-fledged sponsor but I'd love to see a donate function to their site. Once this is released if the CA is trusted by all the major browsers I am more than willing to shift all the money we spend in certs from all these other "authorities" to something constructive like this.
Launching in 2015: A Certificate Authority to Encrypt the Entire Web
401–410 of 476 posts
Re: Launching in 2015: A Certificate Authority to Encrypt the Entire Web
#402Earlier quoted context omitted.
The solution is something nobody hasn't quite come up with. SSH has. It tells me: WARNING, You are connecting to this site (fi:ng:er:pr:in:t) for the first time. Do your homework now. IF you deem it trustworthy right now then I will never bother you again UNLESS someone tries to impersonate it in the future. That model isn't perfect either but it is much preferable over the model that we currently have, which is: Bli…
...and then if the fingerprint changes, you get something like this: @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ @@@ WARNING! THIS ADDRESS MAY BE DOING SOMETHING NASTY!! @@@ @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
... and then you do rm .ssh/known_hosts and try again :P
Re: Launching in 2015: A Certificate Authority to Encrypt the Entire Web
#403Earlier 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.
Authentication and encryption are fundamentally separate ideas, and the problem here is that the CA system mixes them together, when an optimal solution (read: encryption everywhere) would be to tackle them separately.
Encrypted (Certified) AUTHENTICATED & ENCRYPTED
Encrypted (Self-Signed) NOT AUTHENTICATED & ENCRYPTED
Unencrypted NOT AUTHENTICATED & NOT ENCRYPTED
Connecting to a blog? Encryption is a plus (and is the topic of this very HN post). But unencrypted is also okay.
The original CA system was not designed to defend against mass surveillance so it had little incentive to separate these concerns.
Re: Launching in 2015: A Certificate Authority to Encrypt the Entire Web
#404Earlier 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…
The solution is something nobody hasn't quite come up with. SSH has. It tells me: WARNING, You are connecting to this site (fi:ng:er:pr:in:t) for the first time. Do your homework now. IF you deem it trustworthy right now then I will never bother you again UNLESS someone tries to impersonate it in the future. That model isn't perfect either but it is much preferable over the model that we currently have, which is: Bli…
> SSH has.
IMHO no. We don't SSH to the same 46 servers everyday. But we do log into that many (or more) websites. Can you imagine the amount of homework users need to do in order for this to work?
Not to mention the amount of non-tech savvy users who just won't put up with it.
Re: Launching in 2015: A Certificate Authority to Encrypt the Entire Web
#405Earlier quoted context omitted.
Certificate Patrol can give you something like this for Firefox.
+1 for Certificate Patrol; used to use it until it got too annoying for me. Same with RequestPolicy; another great extension that is unfortunately a lot of work if you surf a lot, esp these days, when everything is hosting assets on CDNs.
I used to use EFF's SSL Observatory until I realized it spits out lots of extra http requests. X509 is inherently flawed/complex and adding a browser plugin to make it better feels wrong.
Re: Launching in 2015: A Certificate Authority to Encrypt the Entire Web
#406Earlier quoted context omitted.
Regarding your first paragraph, I agree: all CAs need continuing scrutiny. Certificate Transparency, for example. Regarding the rest of your post, however, I'm calling bullshit. You give very bad advice. Deploy TLS on every website . Deploy HTTP Strict-Transport-Security wherever you can. The sites people visit are confidential, and yes, are not protected enough at the moment. (That will eventually improve, piece by…
kindly cite Black Hat 2009, "Why TLS Keeps Failing to Protect", Moxy Marlinspike, slide 42: https://www.blackhat.com/docs/us-14/materials/us-14-Delignat... Basic concept: 1) find target site A with shared SSL cert. Cloudflare gets shared SSL certs with 50+ unrelated domains. 2) find vulnerable server B in a domain on same cert. (Probably Wordpress.) 3) attack server B, inserting fake copy of important pages on site A…
Wrong.
5) Cloudflare's sni??????.cloudflaressl.com presents an error to you because the Host: header is either missing, doesn't match the SNI, or otherwise, serves the correct site to you instead of your phishing page.
You obviously haven't tested this. And it's Moxie.
Vhost-confusion is a relevant attack on TLS with non-HTTP protocols, HTTP/0.9 and sites which serve a default domain to clients with no Host: headers. Cloudflare quite specifically does none of these, and is not vulnerable in its deployment - it needs the Host: header to know which site you want it to select with its reverse-proxy, and you can't poison that because it's protected by TLS to Cloudflare.
Also you, the attacker, don't have the cert.
If you can DNS poison away from Cloudflare, please report it to their security team, but you'll find they're looking at deploying DNSSEC soon.
Re: Launching in 2015: A Certificate Authority to Encrypt the Entire Web
#407Earlier quoted context omitted.
...and then if the fingerprint changes, you get something like this: @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ @@@ WARNING! THIS ADDRESS MAY BE DOING SOMETHING NASTY!! @@@ @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
... and then you do rm .ssh/known_hosts and try again :P
ssh-keygen -f ~/.ssh/known_hosts -R 123.45.67.89
Re: Launching in 2015: A Certificate Authority to Encrypt the Entire Web
#408Earlier quoted context omitted.
> a hobbyist deciding to write their own web server would not be one of them nginx started out as a hobby project by Igor Sysoev. Maybe he should have just used Apache too? > Or at the very least you could let another process to TLS termination and just handle HTTP A well-designed HTTPS->HTTP proxy package could work. Install proxy, and requests to it on 443 fetch localhost:80 (which you could firewall off externally…
FWIW, Igor did code up nginx to support HTTPS, despite terrible SSL libraries :) I don't really understand the problem you are having. If your sites are small personal/side projects, why worry about things like your web server? That stuff is so trivial, it's boring. If your sites are so large that the overhead that HTTPS has over HTTP makes that much of a difference (pretty sure that'd be Google, Facebook, Twitter, a…
> why worry about things like your web server?
I want to do different things that haven't really been done before.
I want to write my site in C++ instead of PHP. In my own case, it's not as much about speed (that's a free benefit), it's more about the language: I favor the strong typing, compile-time checking and stronger inheritance model. What I envision is that I have C++ source files. I upload one, the server sees there is no binary for that page, and invokes Clang to build it when the page is accessed, and caches the binary for future use. Once I upload the source again, and the modified timestamp is newer than the binary, it rebuilds the cached binary.
I also have a lot of parsing built-in to the server itself to do things like Markdown/Stylus, but optimized for what I need (my syntax generates automatic anchors and TOCs for sections, great for documentation.)
I also plan to code up a forum so that I don't have to run phpBB, and thus don't have to run PHP and Apache.
I can also test my server on my local desktop without having to install PHP+Apache. I just open my server binary, and go to localhost in my browser.
> in 2014 if you develop a web server that doesn't work with HTTPS, it's pretty much dead on arrival.
Exactly! That's why I want to support TLS. Yet they've made that as difficult as is humanly possible, it seems.
> This sounds like exactly what you need.
Yes, libtls is exactly what I need, and mentioned before. Its limitations are that it's not available in my package manager, and hasn't had a lot of real-world testing yet (though I trust the OpenBSD team.)
In 6-12 months once this is easily usable on Windows, OS X, Linux and FreeBSD, I'll definitely be giving it a shot.
But isn't it sad that it's 2014 and a library with this level of simplicity only just came out 2-3 weeks ago?
Re: Launching in 2015: A Certificate Authority to Encrypt the Entire Web
#409Earlier quoted context omitted.
> If it's public static content, what is SSL protecting? In this case, SSL protects against MITM attacks. If a customer goes to the unencrypted "example.com" site and gets a bunch of ads for porn, it will give the customer a negative impression of the company. All it would take is a few pitchfork-wielding high-profile twitter accounts to cause a PR nightmare. Even if the cause is a hacked coffee shop wireless access…
> especially since a basic SSL certificate is free From where? StartSSL only gives out free certs to individuals. For my company, they've actually required me to get organizational validation in the past, which wasn't cheap ($200, IIRC—$100 for the organizational validation, plus $100 for stage 2 personal validation, which also required me to upload images of my driver's license and passport).
Domain validated certs for websites are free, got one a couple of weeks ago for a site.
Re: Launching in 2015: A Certificate Authority to Encrypt the Entire Web
#410Earlier quoted context omitted.
The solution is something nobody hasn't quite come up with. SSH has. It tells me: WARNING, You are connecting to this site (fi:ng:er:pr:in:t) for the first time. Do your homework now. IF you deem it trustworthy right now then I will never bother you again UNLESS someone tries to impersonate it in the future. That model isn't perfect either but it is much preferable over the model that we currently have, which is: Bli…
> SSH has. IMHO no. We don't SSH to the same 46 servers everyday. But we do log into that many (or more) websites. Can you imagine the amount of homework users need to do in order for this to work? Not to mention the amount of non-tech savvy users who just won't put up with it.
Quite the contrary: SSH's system means that you only have to "do your homework" when first connecting to the server. It seems I have 64 lines in my ~/.ssh/known_hosts (there are probably quite a few duplicates, because this seems high to me) and almost never have SSH tell me the key has changed and someone could be doing something nasty. When it does, I almost always know why, and when I don't then I try to contact the admin before connecting.
The way certificate authorities work though, you might visit your bank's "secure" website everyday, with its green padlock and company name displayed, but if one day a rogue authority or a compromised one issues a certificate to someone else, and your DNS resolves to a new server, your browser would not even tell you anything has changed and would happily display the green padlock like it always has.
In the current state of things, you have to do the homework yourself for every site you visit when using HTTPS, while you don't with SSH.