Slashdot Mirror

The article says that browser makers rushed to put out patches to blacklist the fraudulent certs. Isn't this what certificate revocation lists are for? Are CRLs completely broken and unused?

As a matter of fact, yes. SSL revocation mehcanisms are broken and nobody knew until a few days ago. Jacob Appelbaum wrote a nice write-up yesterday about how he noticed the emergency patches in Firefox and Chrome regarding blacklisted SSL certificates.

Are CRLs completely broken and unused?

Yes, they are.

Uhh, if someone can block access to CRLs, what's to stop them blocking access to WindowsUpdate or Mozilla update?

You may want to read http://www.imperialviolet.org/2011/03/18/revocation.html

Are CRLs completely broken and unused?

Yes, they are.

I’m no HTML technician, however I would assume it requires significantly more processing power. Your personal blog or website with 10 hits a day sure, run it over https and you probably wouldn’t notice much difference (aside from the cost of your own unique IP address). A large scale site however would probably have more hardware and bandwidth requirements to implement https on everything.

Actually, not really. If you do it right, the performance impact from using SSL is negligible. Take a look at this article: http://www.imperialviolet.org/2010/06/25/overclocking-ssl.html

Gmail was switched over to https, and this is what the folks who did this have to say about the performance impact (from the link above):

In order to do this we had to deploy no additional machines and no special hardware. On our production frontend machines, SSL/TLS accounts for less than 1% of the CPU load, less than 10KB of memory per connection and less than 2% of network overhead.

In January this year (2010), Gmail switched to using HTTPS for everything by default. Previously it had been introduced as an option, but now all of our users use HTTPS to secure their email between their browsers and Google, all the time. In order to do this we had to deploy no additional machines and no special hardware. On our production frontend machines, SSL/TLS accounts for less than 1% of the CPU load, less than 10KB of memory per connection and less than 2% of network overhead. Many people believe that SSL takes a lot of CPU time and we hope the above numbers (public for the first time) will help to dispel that. If you stop reading now you only need to remember one thing: SSL/TLS is not computationally expensive any more.

Hardware costs would soar if they switched entirely to HTTPS. There is an entire industry making crypto co-processors to handle the load that millions of concurrent HTTPS connections place on an infrastructure.

SSL accelerators are useful for offloading the CPU-heavy part of the SSL transaction: the RSA key-exchange part. The rest of the secured connection is quite light, particularly when using a fast cipher like RC4. The RSA part can be sped up by using shorter keys (e.g. a 1024-bit key, rather than 2048 or 4096-bits), while still providing modest security (anything is better than nothing).

That this guy, a Google employee, said the following about SSL:

In January this year (2010), Gmail switched to using HTTPS for everything by default. Previously it had been introduced as an option, but now all of our users use HTTPS to secure their email between their browsers and Google, all the time. In order to do this we had to deploy no additional machines and no special hardware. On our production frontend machines, SSL/TLS accounts for less than 1% of the CPU load, less than 10KB of memory per connection and less than 2% of network overhead. Many people believe that SSL takes a lot of CPU time and we hope the above numbers (public for the first time) will help to dispel that.

If you stop reading now you only need to remember one thing: SSL/TLS is not computationally expensive any more.

Much like the SSL cert ecosystem today provides a means of merchant identification, without there either being a single point of failure or sinister government control.

Actually, as it's currently implemented, the SSL cert ecosystem today provides many points of failure and sinister government control that compromise the whole system. Count the number of "trusted" root CAs in your web browser -- any one of them can be evil, compromised by crackers, or agree to government intrusion in order to compromise any your web-based communications. Here's a more in-depth analysis of the problem. Even worse, these "trusted" roots can create subordinate CAs, which can in turn compromise all of your X.509-secured communications. You might also be interested in the EFF's SSL Observatory, along with their analysis of the abysmal state of today's X.509 certificate infrastructure.

To solve this properly, we'll probably need to do at least the following:

• enable multiple paths of certification for any certificate -- X.509 only allows one issuer per certificate (OpenPGP allows an arbitrary number).
• provide tools to let users indicate scoped reliance on certifying authorities. For example, you might be fine with using the US Government's certifying authority to identify https://www.irs.gov/ (note: the IRS currently uses akamai's CDN, so TLS is entirely broken for it). But you might not want to accept their certifications for https://slashdot.org/ (note: slashdot doesn't currently use TLS properly site-wide either, even though it should) or any other site that is frequently critical of the US government.

I agree that we need work on distributed trust infrastructure. That's why i contribute to the monkeysphere project -- we're pushing OpenPGP-style multi-party, user-centric certification into SSH, the web, and everywhere else we can.

I'm just not convinced that the US Government is likely do this the right way. It seems probable that they'll be happy with centrally-controlled, single-trust-path certification. Or that they'll botch it in the same way that X.509 is currently botched.

That is absurd, because modern hardware can establish 1500 sessions per core per second if using 1024-bit RSA keys[1]. While going to 2048 bits will take longer, you are claiming it will take over 16 times longer to establish a 2048 RSA session. That does not sound right to me.

[1] http://www.imperialviolet.org/2010/06/25/overclocking-ssl.html

So far I've not seen anyone implement any specification. This is the only real effort so far:

1. http://www.imperialviolet.org/2010/08/16/dnssectls.html

2. Dan Kaminsky released Phreebird which includes Phreeload which is a library on top of OpenSSL to verify certificate fingerprints using DNSSEC and a TXT-record.

And what about their bandwidth usage?

Less than 2%. Before you ask, the RAM overhead was under 10 KB/connection.

Seriously, the old "but SSL overloads the servers" crap is completley out of date. It costs a *tiny* bit more, yes, but the end result is far better.

Source: http://www.imperialviolet.org/2010/06/25/overclocking-ssl.html

Not necessarily true, Google have a solution which means that

SSL/TLS accounts for less than 1% of the CPU load, less than 10KB of memory per connection and less than 2% of network overhead

Several approaches are being investigated; see
http://code.google.com/p/chromium/wiki/LinuxSandboxing
http://lwn.net/Articles/332974/
http://www.imperialviolet.org/2008/11/27/sandboxing-on-linux.html

Well, either alangley is taking advantage of the Google Hosting and sortof the brand, or he's actually a Google Employee doing this type of stuff on his free time.

>

Are we supposed to like Google or not now?

I'm confused :(

Realizing that large corporations consist of many separate interests might help alleviate your confusion :-)

Project owner's page is at: http://www.imperialviolet.org/ if you wanted more info.

See my other post with links on how to setup TLS for your mail server, more info on building the web-of-trust, and GPG downloads for your windows friends.

http://yro.slashdot.org/comments.pl?sid=132181&cid =11046941

Also note that the ======== http://link ======== at the end of the parent post has been mangled by Slashdot Submissions Co. and should be fixed before forwarding it on to your friends, or posting anywhere. Broken links have never impressed anybody.

WTF - Here are some links from the link above again. Sorry about the bandwidth wastage but I think it's worth people seeing as practices contained within are sure to benefit us all (in Utopia - yay!)

[--snip-- (abridged) ]

WinPT :: Windows Privacy Tray [sf.net] is a good place to direct your friends still using windows.

I think a resource for mail administrators on how to add TLS capabilities to their SMTP handlers could be healthy for the net as well. On there would be step by steps on how to TLS-enable sendmail, postfix, qmail, proprietary-this, and proprietary-gateway-that.
:: Sendmail
:: Exim
:: Qmail

If you're running Postfix you've got little excuse to not be running TLS.
http://article.gmane.org/gmane.comp.encryption.gen eral/979

My SMTP traffic is opportunisticly TransportLayerSecure. Is yours?

Get a free server certificate from cacert.org If you haven't already you should add their Root Certificate to the list your browser accepts. They will also remotely sign your PGP/GPG keys and issue free S/MIME certificates as well. Very cool, totally free, and a distributed trust model rather than a top-down, it'll-cost-you-$199.00-for-an-SSL-cert model.

For more keysigning fun DO NOT MISS http://biglumber.com/! Find people nearby and extend your web-o-trust.

Host a keysigning party at] your next LUG [debian.org] meeting .

You can get a email-address-verified signature at http://www.imperialviolet.org/keyverify.html

Learn about using subkeys .

- - - - - - GPG keys -- The new web. - - - - - - -

[--snip-- (abridged) ]

Does anybody know of a good clearinghouse with information on plugins for a variety of mailers I could send my dad, high school friends, or grandmother to?

Anybody know of a list out there that collects information on how to secure your email, what's it's all about, and general key maintainence issues (for "the everyday net user")?

WinPT :: Windows Privacy Tray is a good place to direct your friends still using windows.

I'd like to be able to say to a friend: "Here's my key. Go to keepitprivate.com and find a plugin for the email software you use. Then next time you send me some email, just be sure to put it in an "envelope" (it just takes one extra click or can be set to happen automatically). You don't even need to lick a stamp! I value your privacy as much as I hope you value mine!"

I think a resource for mail administrators on how to add TLS capabilities to their SMTP handlers could be healthy for the net as well. On there would be step by steps on how to TLS-enable sendmail, postfix, qmail, proprietary-this, and proprietary-gateway-that. My SMTP traffic is opportunisticly TransportLayerSecure. Is yours?
Red Hat :: Sendmail
:: Exim
:: Qmail

If you're running Postfix you've got little excuse to not be running TLS.
http://article.gmane.org/gmane.comp.encryption.gen eral/979

Get a free server certificate from cacert.org If you haven't already you should add their Root Certificate to the list your browser accepts. They will also remotely sign your PGP/GPG keys and issue free S/MIME certificates as well. Very cool, totally free, and a distributed trust model rather than a top-down, it'll-cost-you-$199.00-for-an-SSL-cert model.

For more keysigning fun DO NOT MISS http://biglumber.com/! Find people nearby and extend your web-o-trust.

Host a keysigning party at your next LUG meeting.

You can get a email-address-verified signature at http://www.imperialviolet.org/keyverify.html

Learn about using subkeys.

- - - - - - GPG keys -- The new web. - - - - - - -

here.
version 1.16 is ok.
others have fixes, too, you can find them in this place.

hope I have helped,

The Eponymous Mallard
"If it quacks like a duck, it's the Eponymous Mallard."

Does anyone know how to do this with DJBDNS?

... can be found at http://www.imperialviolet.org/dnsfix.html

AGL

Patches for DJBDNS and lots of other daemons here.

For all those with an IPTABLES gateway/firewall, imperialviolet.org has a fix :D

For all those with an IPTABLES gateway/firewall, imperialviolet.org has a fix :D

Is at http://www.imperialviolet.org/dnsfix.html AGL