Slashdot Mirror

some web browsers don't even check whether a certificate has been revoked.

This is a sloppy and invalid slur, hiding behind vagueness (it's a bogus criticism of Chrome). Revocation is useless when you fully work the threat model, and similar designs to address the uselessness are probably not workable. Remember, unless a scheme can handle revoking ~every certificate at once, it's inadequate recovery for Heartbleed. It's also a privacy problem because it lets CAs build a log of all web traffic.

The best incremental refinement is short-lived certificates auto-issued by intermediate CAs. CRLSet can revoke intermediate CAs. For normal certs, don't reissue and let them expire. That's basically what lets encrypt is, except "short-lived" is not short enough, like a day or two, yet. Also, as they point out, "weakest link": it's not a real answer unless every CA does it because an undeserving attacker could get someone to sign a long-lived cert for your domain even if you use short-lived ones. But this is the bog-obvious PKI refinement that's currently fashionable. The two-tier system keeps the CRL small, and the certs subject to "confirmation" (by not appearing in the latest short-lived CRL) can be backed by HSM that can't sign things quickly but is very unlikely to sign things wrongly.

The refinement being pushed instead of the obvious one is "OSCP stapling" and perhaps "must-staple", because this preserves the CA cartel. Without some long-lived rare magical token to give you, it's difficult to convince you that you owe them lots of money, so we still give you the token as a pacifier but then implement the above sane scheme in rube goldberg fashion, moving what should be the cert into the stapled confirmation.

However I think the correct response is not the obvious refinement. It's a major rethinking of the architecture, like Sovereign Keys. In this scheme, you must give up privacy to some central server because you must do lookups on a structure too big to store locally, but you can choose to whom you give it up because the structure is a blockchain that anyone can sync. Actually it might be small enough to store on a single computer so no big deal, but even if it weren't it's still less bad than OSCP privacy because of the option of picking a mirror you "trust".

Fixed link: RISC-V assembly (31 Dec 2016)

Consider how incredibly dangerous it is to write code that's not actually indented the way it's meant to be executed. Lots of eyes looked at that C code and didn't notice that the formatting was inconsistent with its parsing. That would not have been a problem in a language that uses indent to describe intent.

Braces are also pretty explicit about how you want it executed.

Yes, but you save time by not indenting

I'm asking this seriously: what text editor do you use that you can easily not indent? I use Emacs (and Vim and Sublime Text and Atom) and automatically get thr correct indentation just by writing code like I normally would. If I type if foo: and hit enter, the cursor will be placed correctly for the next thing I type. This isn't Python-specific, either. I get the same behavior when writing C, Go, JS, shell scripts, and so on.

I love dealing with a language that's explicit about what I mean. Consider how incredibly dangerous it is to write code that's not actually indented the way it's meant to be executed. Lots of eyes looked at that C code and didn't notice that the formatting was inconsistent with its parsing. That would not have been a problem in a language that uses indent to describe intent.

Remember when Google switched GMail from HTTP to mandatory HTTPS back in 2010? You know what they had to do to cover the new TLS overhead in CPU, memory, and network bandwidth? Nothing. The biggest thing they did was patch OpenSSL to reduce memory per connection, and that patch has already been integrated upstream.

I'm not saying the other issues aren't real, but overhead is really unconvincing unless your network load balancer is a potato.

Did we already forget?
https://www.imperialviolet.org...

int err;
if ((err = PrepareHash(x,n)) != 0)
    goto fail;
    goto fail;
if ((err = CalculateHash(x,n)) != 0)
    goto fail;
return CompleteHashx,n);

fail:
return err;

I don't think he was talking about heartbleed. I think he was talking about GOTO FAIL

bcp38 stops people from using fake IP addresses. That does not solve the problem in general. If my pipe (or collection of pipes) is bigger than your pipe, I can still destroy your service. While it seems like many people here don't think you can do better, there are some more options.

First let me say this is not my field. It's been a couple years since I studied BGP, but since I don't see anyone posting robust solutions, I'll provide my hand waving arguments and proposals. I will not claim any of this is practical, but I do think it is technically possible (costs and performance aside).

Note that other limited bandwidth fair delivery systems (email, physical mail, Tor hidden services etc) all have the same set of problems.

Given that you can purchase DoS (distributed or not), there is the question on if enabling this (or doing it) is illegal. The legal solution either doesn't work, or bans proxies like Tor. Thus I don't consider it a valid solution.

There is also the approach of changing service models: some services can operate by simply publishing messages (DNS is an example, but so are news sites without user interaction). These don't have to depend on the packet switched network directly, and can use distributed content based models, like Freenet that get around the problem of having to host your own stuff. I don't see how this can generalize too well (there's lots of overhead and latency), but Bitmessage is an interesting example of using publication + encryption for private messaging.

Also there are cost and payment based approaches: suppose I had to pay the cost of delivering and processing my packet to send it to you, or provide some significant proof of work. Ripple does this but that's just one example. I'm not aware of ideas for how to scale this to IP scales (the stateless packet based nature makes it really hard). I think Skycoin is trying, but they aren't far enough along convince me it's possible.

Now for my crazy ideas: Suppose we could deploy a system for pay for processing to establish a session with the service, and after that we could continue to the the session, and perhaps resume it long into the future (ex: you get a shared secret or a private key, and put it in a cookie). Once authenticated, you could then use a network that only allows solicited traffic. This is possible: for example once connected to a Tor hidden service, you have a route to it which can be closed off if you abuse it, but other people are unable to flood the route, and the service could stop accepting new routes leaving your existing connections safe from DDoS. Tor hidden services don't have an DDoS resistant way to "sell" routes/sessions, but that could be fixed (Send bitcoins to proper address, and the details you need will be published encrypted with your public key. Of course the bitcoin network has DDoS problems of its own, but lets not recurse here, assume you have something to fill that role that is DDoS resistant, maybe like Ripple?).

So we have a proposed design that solves this problem for Tor hidden services. We should now be able to exploit the homomorphisms here and fix and the internet (IP) and email (left as exercise for the reader, but I recommend adding a key selling scheme to Pond if you care about privacy, because screw plain text email). So focusing on the internet, if you then had a system where only people owning valid sessions could transmit to the service (at some other IP or set of IPs) enforced at entry to the internet (ISP level I guess), then you have a setup where DDoS can't effect existing users which is a huge win, and if you make get an auth system to be DDoS resistant (needs some payment or proof of work setup) then it's pretty much DDoS resistant.

So how can we filter traffic based on permission/keys/session to particular addresses? We could allocate some massive block of IPv6 address

https://www.imperialviolet.org...

This affects BigIP F5 and A10 load balancers which implement TLS incorrectly.

The impact of this problem is similar to that of POODLE, with the attack being slightly easier to execute–no need to downgrade modern clients down to SSL 3 first, TLS 1.2 will do just fine.

This seems like a good moment to reiterate that everything less than TLS 1.2 with an AEAD cipher suite is cryptographically broken. An IETF draft to prohibit RC4 is in Last Call at the moment but it would be wrong to believe that RC4 is uniquely bad. While RC4 is fundamentally broken and no implementation can save it, attacks against MtE-CBC ciphers have repeatedly been shown to be far more practical. Thankfully, TLS 1.2 support is about to hit 50% at the time of writing.

I am terribly confused. Is or isn't worth upgrading to TLS 1.2?

I am stuck with TLS 1.0 on FireFox v10 ESR. Tried v24, and it's just ick with the one of the bugs that I 'first' encounted with v17 with my "setup". "Up and down shaking" with my tab 'setup' if you're curious. I use two rows of tabs. And v31 is totally broken in a frustrating way. I may be able to manage v24 if I'm forced to, but I don't want to upgrade if I don't have to. (I wish Mozilla would just do security patches for all the ESRs. Not bug patches, but security patches. Wasn't that the point of having an ESR with which to begin?)

tl;dr For those of us on TLS 1.0, do we need to do anything, or is it something only server/website admins need to do?

https://www.imperialviolet.org...

in short, there is no cpu overhead anymore, in today's compute systems. https is not a barrier due to processing, at least.

us-cert.gov doesn't give really give you enough info. Look here for a fix that fits within the protocol. No one wants to do any serious work on it though because SSL isn't worth it.

according to google, essentially NO extra cpu (in real terms) is needed anymore.

citation:

https://www.imperialviolet.org...

quote:

If there's one point that we want to communicate to the world, it's that SSL/TLS is not computationally expensive any more. Ten years ago it might have been true, but it's just not the case any more. You too can afford to enable HTTPS for your users.

From agl:

We used to have an entry in the preferences for that but people thought that “SSL 3.0” was a higher version than “TLS 1.0” and would mistakenly disable the latter.

"Chrome Users Dumbed Down" might have been a more apt title.

First reactions are generally positive. Theo de Raadt comments, "Choice is good!!."

The name "BoringSSL."

I am finding extreme difficulty in liking this name choice. What was Google thinking? Am I alone?

It's not "What was Google thinking?", it's "What was Adam Langley thinking?". As for what he was thinking, it's pretty simple: Fundamental security components like SSL/TLS should be very, very boring. They're not a place for innovation and experimentation, they're not a place for clever code that demonstrates the author's virtuosity (assuming there is any such place, outside of Obfuscated C contests). They're not a place for exploration of how the C preprocessor can be used to automatically generate much of the codebase (which is something that OpenSSL has done). They're where you want very simple, straightforward, boring implementations of industry best practice algorithms and protocols.

When it comes to security, boring is good.

As Langley said in his blog post, the name is aspirational. But it is his goal, to produce a security library which is completely boring. And it's a good thing.

Here's what a Chrome developer said about it back then, and here's his twitter where he keeps on explaining now

That's utterly crap advice. Since a lot of softwares in popular, active use have critical vulnerabilities.

The example quoted just above (http://ask.slashdot.org/comments.pl?sid=4862577&cid=46414687) in which nobody got the sarcasm... says:

You know there won't be any bugs in those, or if there are they'll be very quickly fixed and not sit there unnoticed for years.

He was referring to https://www.gitorious.org/gnut... and https://www.imperialviolet.org..., not to mention http://bsd.slashdot.org/story/... which also sat unnoticed for years.

I just checked with https://www.imperialviolet.org... And I got the message "Safari can't open that page because Safari can't established a secure connection to the server". I am running Mac OS 10.8.4 so does that mean I am safe?

I get
The webpage at https://www.imperialviolet.org... might be temporarily down or it may have moved permanently to a new web address.
Error code: ERR_FAILED

At mine, the test site at https://www.imperialviolet.org:1266/ does not even load. Firefox says:

Secure Connection Failed An error occurred during a connection to www.imperialviolet.org:1266. A PKCS #11 module returned CKR_DEVICE_ERROR, indicating that a problem has occurred with the token or slot. (Error code: sec_error_pkcs11_device_error)

Snow Leopard (10.6) is not vulnerable to this bug, since Apple did not switch from OpenSSL to their own SSL/TLS library back then yet. Just verified on my 10.6 box (to verify visit https://www.imperialviolet.org... )

On the other hand, iOS 6.1.5 is - and now I have a choice of using insecure iPhone or upgrading to 7.x.

Or, perhaps upgrading to iOS 6.1.6 which corrects that bug.

Some bloggers and commentators online (no mainstream media news sites... yet) have suggested that this bug was introduced by the NSA based on the fact that Snowden's leaked slides showed evidence that the NSA had developed and was working on further ways of targeting and compromising secured iOS traffic.

We know the NSA compromised RSA through Dual EC_DRBG. It's not hard to imagine they wanted to compromise SSL/TLS on Apple platforms.

The bug was found via internal code review according to the credits for discovery, which means nobody else has disclosed they knew about this in the wild (so this is an exposed zero day crypto exploit on both OS X and iOS platforms).

This link is informative - the kicker is he properly indented but obviously duplicated and incorrect "goto fail;"

https://www.imperialviolet.org...

static OSStatus
SSLVerifySignedServerKeyExchange(SSLContext *ctx, bool isRsa, SSLBuffer signedParams,
                                                                  uint8_t *signature, UInt16 signatureLen)
{
        OSStatus err; ...

        if ((err = SSLHashSHA1.update(&hashCtx, &serverRandom)) != 0)
                goto fail;
        if ((err = SSLHashSHA1.update(&hashCtx, &signedParams)) != 0)
                goto fail;
                goto fail;
        if ((err = SSLHashSHA1.final(&hashCtx, &hashOut)) != 0)
                goto fail; ...

fail:
        SSLFreeBuffer(&signedHashes);
        SSLFreeBuffer(&hashCtx);
        return err;
}

Maybe this came out due to bad coding practices, but the kind of bug where the code visually looks ok on the surface, compiles and passes without compiler warnings, and works fine aside from allow the comprise is very suspect.

And at the minimum the NSA has been exploiting this rather than alerting people. Our government needs to stop weakening computer security and go back to working for the people, not against them.

Given this bug exists in published open source code, I'm not sure how your point is relevant to this particular issue.

https://www.imperialviolet.org...

Open source code is not a panacea. Have you not been paying attention to the number of RHEL kernel updates (to pick one example) released in 2014?

I used the test site set up at https://www.imperialviolet.org... with a X.6.8 rig using both Safari and FF. It passed with flying colors.

Does this mean earlier versions of OS X don't have the bug?

Yeah, you'd think a compiler should have caught that.. but neither GCC or Xcode seems to do that..

Adam Langley has a great blog post dissecting this:
https://www.imperialviolet.org...

I see a few problems with this approach:

1)Not all content is provided over both HTTP and HTTPS. For multiple reasons, one being performance. Which leads us to the second problem...

True, which is why HTTPS Everywhere only enables HTTPS on sites that support it (they are specifically whitelisted by the extension devs).

2)A HTTPS session incurs a significant overhead for encryption. Which may be no problem for someone like Google. But for someone hosting his/her own (moderately successful) website on a small server, it might just overload said server.

While HTTPS does incur some overhead, it's surprisingly small for modern servers. Google, for example, was able to add SSL/TLS to all Gmail connections with no new hardware, no additional servers, and SSL/TLS accounts for only about 1% of their CPU time (see here for details).

Pretty much any server will reach other bottlenecks before the slight overhead of SSL/TLS becomes an issue. Using Perfect Forward Secrecy is important for security and using DHE-based ciphers do incur a moderate overhead compared to non-DHE ciphers (a factor of about 3). Using ECDHE instead makes the increase in overhead only about 15% rather than 300%. See here for details.

3)Quite possibly the biggest problem with HTTPS is the fact that users have been trained over many years to just click "accept/install certificate" on self-signed certs. Not knowing that if you do this you are no longer secure.

And the more we keep forcing HTTPS, the more webmasters will use self-signed certs. Not many people want to go through the hassle of obtaining (and maintaining!) a valid SSL certificate for every single website they run, even if that cert is free. Which will only exacerbate the problem...

[citation needed] Getting a domain-validated SSL cert from publicly-available CAs is the work of a few minutes and, as you point out, often available for free or very low cost. Many hosts will automate the generation of a private key and CSR, making the process one of copy-paste for the customer. Other hosts handle the entire process of generating a private key, getting it signed by a CA, and configuring things correctly.

Sure, some sites use self-signed certs, but these are usually for personal or internal corporate purposes and not for the general public. The scary warnings in browsers aren't likely to go away anytime soon, so I doubt that any webmaster of a website meant for public use is going to be using self-signed certs (other than those catering to specific, tech-savvy audiences).

True, but it would prevent the insertion of malicious packets (the "Quantum Insert" technique they describe in the various articles). Invalid SSL/TLS packets would simply be discarded and it would not be possible to insert malicious packets into the encrypted, MACed datastream.

Yes, MITM would be possible but Slashdot could implement certificate pinning (either through having browsers like Chrome have the cert details baked-in, or having users use something like Cert Patrol for Firefox) to make this harder. It's not foolproof, but it would certainly make this type of attack considerably more difficult and easier to detect.

while providing them with no value

The value is more visits from viewers who trust a site more because their sessions won't get hijacked.

And it's not just a one-time certificate purchase, it's a bunch more powerful servers to do this encryption

You mean 1% more powerful? On a site that isn't just a bunch of static pages, the server power needed by the web application usually outweighs the server power needed by HTTPS on the front end servers. The question becomes whether trust from users is worth this 1%.

A few months ago, Google removed the ability in Chrome to staple a TLS/SSL certificate to your DNSSEC-signed DNS records: https://www.imperialviolet.org/2011/06/16/dnssecchrome.html

It was finally a way to get an HTTPS secured website without needing to go to a CA. And they removed it.

I just thought they were being incompetent as they usually were, but now I can't help but wonder if the NSA got on their backs about not being able to sign their own replacement certificate...

That is all pretty useless if they did that, Chrome would start to complain because it enccounters a different public key. Because Chrome has certificate pinning:

https://www.imperialviolet.org/2011/05/04/pinning.html

Check out Pond, by Adam Langley. It's Tor based secure end to end mail with a variety of interesting tricks, done by a real cryptographer (one of the people who upgraded OpenSSL to support forward secrecy, and then upgraded Google to use it).

You mean like SSL is broken and nobody talks about it?

First there was BEAST in 2011, which was fixed. But the situation in 2013 is not better!
https://www.globalsign.com/blog/is-ssl-broken.html (and links therein, especially the last two)
https://www.imperialviolet.org/2013/02/04/luckythirteen.html
http://blog.cryptographyengineering.com/2013/02/attack-of-week-tls-timing-oracles.html
List of all attacks: http://armoredbarista.blogspot.de/2013/01/a-brief-chronology-of-ssltls-attacks.html

You can see "delay" with https sites easily, no benchmarks required either. It's just the performance price paid for the (hopefully) added security.

Yes there is added latency due to the handshake, though on my broadband connection I can't say that I can see it. Google has proposed and is implementing several standards to reduce this delay though. Of course the biggest reduction in the effects of latency came with "Keep Alive" which we have now had for years.

SSL session caching/reuse will also probably help on top of "Keep Alive".

You can see "delay" with https sites easily, no benchmarks required either. It's just the performance price paid for the (hopefully) added security.

Yes there is added latency due to the handshake, though on my broadband connection I can't say that I can see it. Google has proposed and is implementing several standards to reduce this delay though. Of course the biggest reduction in the effects of latency came with "Keep Alive" which we have now had for years.

HTTPS would represent a significant hit on the servers CPU load if they're not using cryptographically capable hardware

I thought that myth has been pretty well debunked for quite some time now.

Indeed, and that was on the whole of gmail.

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

Luckily, there actually is work in this direction. DNSSEC authenticated HTTPS is supported in Chrome as of Chrome 14 and is being worked on for Firefox (see also: Wikipedia section on DANE). Of course, it requires DNSSEC and a compatible browser. As browsers get updated slowly, most sites will likely be very conservative about switching over, and those with EV certs never will.

Google's experience when switching to https as default on Gmail.

Interesting bit:

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.

That and Google has been working to reduce the latency of SSL negotiation including the use of False Start (reduce round trips), Next Protocol Negotiation (IETF draft mod of TLS handshake), and Snap Start (OSCP and cert caching). [Scroll to bottom of article for links to these changes.]

This work applies to HTTP/1.1 and will be even better in HTTP/2.0

Yep. It's still a draft, but it's already supported by Chrome. Firefox is working on it but may be waiting for the draft to be finalized. Wikipedia reports that there's a Firefox add-on that does it already, but of course it's not all too useful until a majority of internet users have support for it (general support by mobile browsers will likely take a couple years.... Server Name Indication is still not quite supported well enough to really justify using it despite being several years old).

Well, actually, it's a little different from SNI because there are currently a good number of servers around with self-signed certs. Adding DNSSEC stapled certificates to those would not affect old browsers and get rid of the warnings in new browsers.

He said the services, which browsers are supposed to query before trusting a credential for an SSL-protected address, don't make end users safer because Chrome and most other browsers establish the connection even when the services aren't able to ensure a certificate hasn't been tampered with.

So he admits Chrome is broken, so he doesn't fix it and blames the CA's . . makes sense.

Chrome will instead rely on its automatic update mechanism to maintain a list of certificates that have been revoked for security reasons. Langley called on certificate authorities to provide a list of revoked certificates that Google bots can automatically fetch.

So basically he wants CRLs? I thought he didn't want CRLs?

You've made the classic mistake of taking the Slashdot headline seriously. The actual post doesn't say Chrome will stop using CRLs. It says they will be pushed to Chrome directly from Google. No one "admitted" that Chrome is broken. The entire system is broken. All major browsers will load an HTTPS site even if they cannot get the CRL via OCSP because doing otherwise would cause huge amounts of unnecessary breakage and just make users angry and confused. From the actual post:

So soft-fail revocation checks are like a seat-belt that snaps when you crash. Even though it works 99% of the time, it's worthless because it only works when you don't need it.

http://www.imperialviolet.org/2011/06/16/dnssecchrome.html

Is Convergence foundering due to a lack of buy-in from trustworthy allies?

In your BlackHat 2011 talk you announced Convergence as a new way to establish trust on the internet to replace the SSL/Certificate Authority approach that has been shown to be so broken with the recent compromises of CAs like Comodo and Diginotar. Yet potential allies, some of whom admit that SSL has failed to meet its purpose and needs fixing, have not bought in to Convergence. Notably these include Google's Chrome security people and apparently the EFF (who has proposed a different solution instead).

While the list of Convergence notaries is still growing, there is so far a lack of support from the kind of allies like the EFF who could lend credibility and tip momentum toward widescale adoption of Convergence as a solution to the SSL/CA problem. Is Converence wilting on the vine?

For websites that do dynamic content, the processing overhead of properly implemented SSL is close to trivial -- in any case it's not even near "seriously heavyweight". It is potentially more work though and the latency can be noticeable.

If you don't believe me, believe Google Adam Langley: "In order to [switch GMail to HTTPS] we had to deploy no additional machines and no special hardware." "SSL/TLS is not computationally expensive any more." -- and this was almost two years ago.His writeup also explains well the latency problems that still plague HTTPS and how to mitigate them.
Overclocking SSL

Not much:

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.

While the US could muck with the root zone, it would be a one-time event. The root only has records for the TLDs, like .COM, .NET, .CN, .RU.

While the US has mucked with gTLD zones by forcing Registrars in the US to point the DNS to their servers, they have never gone into the TLD zone itself or interfered with the operations of the gTLD zones directly. They could, but going the Registrar route is easier. Going directly to a TLD zone edit would also most likely be a one-time event.

When I say "one-time" event, I mean that if the US touches the root zone outside of the established processes, everyone else is going to insist that the UN or other International body maintain control and/or they will move to a new root under the control of the UN, etc.

As far as a "one-time" event for the gTLDs that the US controls, it will force anyone with any security mindset to move outside those gTLDs. In fact, this may already be the case for most due to the Registrar-based takeovers by the US ICE and others.

What moving to DNSSEC gives you is control at the "dot" level. The US (nor any other country outside of each country's own ccTLD) should have no control whatsoever for any ccTLDs (.CN, .RU, etc.) other than to maintain the root servers which point to the ccTLD NS and the DNSSEC info needed to establish the chain of trust from the root down.

The problem with SSL Root CAs is that they have global authority for all domains. DNSSEC authority is tied to the zone-level.

The problem with both is that a DoS/MitM attack can stop either from working. All I have to do is block DNSSEC records and you just have to say "oh well, I cannot get secure records back." But it is the same situation with a MitM SSL decrypt/encrypt with a fake Root CA (you just have to shrug and known you are not getting a secure connection).

Ultimately I think DNSSEC + CA certs servers/signatures in DNS which are limited to the zone they are for is going to be the way to go. This is going to take support on the Browser Vendors to get on board. Good news is Google Chrome is already on the way.

El Reg has reported on Google's Adam Langley in reponse to Convergence. Langley says' he doesn't see including it in Chrome because users would never change the default notaries, and Google would have to run their own notaries in order to ensure performance. And that would mean a privacy issue for Chrome as it "phones home" every user's https requests to Google. [Doesn't Chrome already have some kind of anti-phishing Safe Browsing feature that does this anyway?]

However Langley was good enough to open the door to the possibility of future API tweaks that would allow a third-party Convergence extension for Chrome (Chrome doesn't currently have a way for extensions to sit in the SSL cert decision path).

In fact in such a situation, a CA outside of the control of your enemies might be your best bet of remaining secure

WRONG! Because most browsers don't warn you if _ANY_ CA (recognized by your browser) in the control of your enemies signs the site's certs. It just takes ONE out of the dozens, does not matter which CA! Recent versions of Google Chrome warn you but only for google's stuff (certificate pinning: http://www.imperialviolet.org/2011/05/04/pinning.html ).

Whereas if you can get the fingerprint of the self-signed cert from some other channel (e.g. get a friend outside the country to tell you), you will know if it is different from expected.

If it is always different from expected, you know you just can't use the site or ISP (which will be the same problem for the CA cert case).

Whereas if the fingerprint is correct you can use the site while it is OK, because most browsers by default will warn you the very moment the self signed cert changes. This is not true for the pwned CA signed cert situation (assuming default browser behaviour).

In contrast, even if you took the trouble to verify the CA signed cert fingerprint via a friend, it does not help - the cert could change later but the browser will NOT warn you!

So tell me again which situation is safer?

I'm not sure if you meant this specifically, but as a nitpick, https itself is hardly CPU-intensive these days. GitHub might be doing CPU-intensive stuff to service requests, but if so, it's more likely to have something to do with their backend than with https.

Anyone know how much every twitter user using ssl would slow down the service?

If Google's experience is any indicator, not much:

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.