Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The SSL Co-operative: A Member-Controlled Certification Authority

sslcoop.org

Post reply on HN
Print view View original

71–80 of 90 posts

Re: The SSL Co-operative: A Member-Controlled Certification Authority

#71

Post by MichaelGG »

ademarre wrote: post #62
michaelbuckbee wrote: post #61

Earlier quoted context omitted.

The problem is that phishers register sound alike domains like info-secure-apple.com or atlanta-usbank.com, that were completely clean prior to issuance.

One could argue that should be okay for a class of certificate without identity/organization verification.

Actually, yeah, they should. Info Secure Apple. Make a comment forum about fruit-borne illness. Why should that be denied because there are companies using one of those words?

What we "need" more of is EV-style validation, so I can see that the site I'm on is an actual company registered in whichever territory. Otherwise all it indicates is that an email address with the associated domain is linked to the private key for this site. Not really what most people are looking for.

Re: The SSL Co-operative: A Member-Controlled Certification Authority

#72

Post by MichaelGG »

leccine wrote: post #58
codezero wrote: post #29

Earlier quoted context omitted.

How is the NSA involved in the currently established CA system?

2 ways, A, creating rogue cert by md5 collisions (they have the capacity) B, making people believe that a CA guarantees the identity of the issuer, while having their CA in the approved list so they can sign certs (for example like gmail.com) There is good documentation about it: http://files.cloudprivacy.net/ssl-mitm.pdf

Except if the NSA did sign Gmail in any non-trivial capacity, it'd certainly be noticed and the offending CA would be removed or put out of business or something like that. Plus it'd draw lots of attention to the NSA directly.

If they did want to sign something publicly, they'd just compromise some third-world CA and have them take the blame. There's plenty of them in there.

Or they could just sign up as a Comodo reseller.

Re: The SSL Co-operative: A Member-Controlled Certification Authority

#73

Post by JoshTriplett »

womble wrote: post #35
JoshTriplett wrote: post #16

Earlier quoted context omitted.

I use and like StartCom certificates, but they wouldn't solve this problem. Wildcard certificates should not require identity validation; you should be able to get a domain-validated wildcard certificate for free. Also, their free certificates expire every year; domain-validated certificates should only require revalidation if the domain changes hands.

There are rules being introduced against issuing certificates for more than about three years (you can still get five years certs at the moment, but not for much longer); this is more to limit the risk of private key compromise than it is to require people to revalidate. I don't find it too onerous to have to install a new cert every year or so (he says, with several certs currently expired).

Still, I'd suggest issuing certificates for the maximum allowed length, unless requested shorter. Scalable revocation is possible; follow best practices for encryption keys by keeping a separate offline copy of a signed revocation request.

Re: The SSL Co-operative: A Member-Controlled Certification Authority

#74

Post by TsukasaUjiie »

womble wrote: post #36
CMCDragonkai wrote: post #9

Earlier quoted context omitted.

It's sad that debian removed them. I think cacert needs more dedicated governance. If all the money we spent on ssl certificates could be pooled together to create non-profit organisation dedicated to public certificates, it would be awesome! And we could probably get opensource PKI infrastructure.

(I'm the sslcoop.org guy) "If all the money we spent on ssl certificates..." And thus was sslcoop.org born! I'm not sure what you mean by "opensource PKI infrastructure", exactly, but as a long time F/OSS hacker, I'm definitely planning on putting everything that's developed for the SSL co-op under an open licence. But the software's the easy bit. The hard part is the work required to define processes and policies, g…

iirc the WebTrust Audit required for such a system is in the ~$100,000 range. Why abandon existing initiatives to start another undermanned community based authority.

I think the focus should really be in jumpstarting CACert (overhauling its governance model) and building on its existing infrastructure and user/assurer base (As an assurer I'm probably biased here).

Of course this would be hard work and less self fulfilling than doing the F/OSS dance and re-inventing the wheel..

Re: The SSL Co-operative: A Member-Controlled Certification Authority

#75

Post by tombrossman »

toast0 wrote: post #52
tombrossman wrote: post #50

Earlier quoted context omitted.

Possibly a stupid question, but why not make whichever vhost is correctly configured for SSL your default? Any traffic will go there unless another match is found. This is what I do to force SSL and redirect anything not matching another vhost. Catch-all + HTTP --> HTTPS server { # Set server name & make it the default for this IP address listen 80 default_server; listen [::]:80 default_server ipv6only=on; return 301…

That's not helpful, he doesn't have a cert for www.sslscoop.org, so the link is http; but if you try https://www.sslscoop.org/ you get a cert error, because the IP(s) are running https, but for a different name. By the time the server can return the redirect you propose, the user agent must have already accepted the non-matching certificate.

Hmm, good to know then. Is there a working Nginx config you can point me to for this use case, because I'd like to solve this issue too. My setup happens to be one HTTPS only server and one HTTP only, but it would be good to know in case I want to mix things up.

Testing a couple third-party sites, our local bus company simply times out when you manually input https://www.libertybus.je. Doing this on the main BBC site https://www.bbc.co.uk/ quickly returns you to the http version. Those are different setups but the cert errors do not happen, which is the goal here.

Re: The SSL Co-operative: A Member-Controlled Certification Authority

#76

Post by womble »

the_mitsuhiko wrote: post #43
blibble wrote: post #7

Earlier quoted context omitted.

it's a superb service, until you want a revocation, then they try to extort $25/revocation out of you (even if you've been a long term paying customer) this may be OK if you have only issued one cert, but if you've issued a few hundred (which is the main point of StartSSL: pay once and issue many), then you are SOL unless you can afford to plonk down thousands of dollars. more here: https://www.techdirt.com/articles/…

Since the revocation protocol is broken anyways I don't really think this is a real problem.

All we have to do is get all certs flagged with must-staple and have all webservers handle stapling, and we're set!

(Sarcasm? Moi?)

Re: The SSL Co-operative: A Member-Controlled Certification Authority

#77

Post by womble »

DoubleMalt wrote: post #41

A couple of questions: - Where do you plan to place the infrastructure of the cooperative? - What is your expected timeline to issue Browser accepted certificates? - Are you planning to provide an API for signing CSRs? I am currently working on a solution for self hosted messaging and file synchronization, and your project would complement our efforts to give people the possibility to self-host securely.

(I'm the SSL co-op guy)

- Probably in Australia, at least at first, since that's where I'm based. I'd like the DR site to be in Europe, if possible, but that might not be a day 1 achievement.

- I'd like to be able to issue certs from day one of the co-op, via a reseller or other arrangement -- that might cost a few dollars per cert, though. It's a minimum of two years from "let's do this!" to being accepted in all the browsers, though (look at the Mozilla inclusion timeline for an idea of best case: https://wiki.mozilla.org/CA:How_to_apply#Timeline)

- An API is definitely intended from day one. My general architecture for these kinds of systems is API for everyone, and the website just talks to the same API that the general public does.

I'd love to talk to you more about how the co-op could help you with your system.

Re: The SSL Co-operative: A Member-Controlled Certification Authority

#78

Post by womble »

dtech wrote: post #44
cs02rm0 wrote: post #30

Earlier quoted context omitted.

I disagree, I think free would be a significant difference. A low barrier vs. no barrier.

But this initiative (however good) will also not provide a no-barrier approach. You need to be a member of the coop (with associated fees) to request certificates. Which is logical. Running a CA and getting the root certificate into the right places is not cheap. Unless someone with money (e.g. Google, as they do with their CDN) decides to provide this service for free some money needs to be earned.

(disclosure: I'm the SSL co-op guy)

All of Google's free services (CDN, DNS, Chrome, etc) are centred around improving the experience of using the web, so more people use it for longer (and, hopefully, do more searches with Google and/or visit more webpages with AdSense ads on them). I'm not sure how more SSL-secured traffic feeds into that, exactly, but if anyone at Google wants to talk sponsorship, I'm all ears...

Re: The SSL Co-operative: A Member-Controlled Certification Authority

#79

Post by womble »

Someone1234 wrote: post #65
aianus wrote: post #49

Earlier quoted context omitted.

Where does it say that? I would assume it's just as easy as issuing them in the first place.

You would assume wrong. Revocation is a massive PITA.

Running a revocation service is an annoyingly fiddly job, but all of that needs to be setup and running before you become a CA. Pretty much all of the faffing around is in the need to regularly regenerate (including signing with the CA key) CRLs and OCSP responder certificates. Like the rest of a CA's operation, revoking an individual certificate should be a miniscule incremental cost, modulo the larger CRL size due to the added fingerprint. I was rather surprised that so many people are sucking down CRLs, but clearly they do (http://blog.cloudflare.com/the-hard-costs-of-heartbleed).

Re: The SSL Co-operative: A Member-Controlled Certification Authority

#80

Post by womble »

JoshTriplett wrote: post #73
womble wrote: post #35

Earlier quoted context omitted.

There are rules being introduced against issuing certificates for more than about three years (you can still get five years certs at the moment, but not for much longer); this is more to limit the risk of private key compromise than it is to require people to revalidate. I don't find it too onerous to have to install a new cert every year or so (he says, with several certs currently expired).

Still, I'd suggest issuing certificates for the maximum allowed length, unless requested shorter. Scalable revocation is possible; follow best practices for encryption keys by keeping a separate offline copy of a signed revocation request.

Revocation for X509 certs is a very different matter to that of revoking PGP keys. For X509, the CA can revoke the cert unilaterally, or at the request of the subscriber without the need for the subject private key. In fact, I'm not aware of the existence of a subject-side revocation process that doesn't involve the cooperation of the CA.
Post reply on HN