Do you run Cert Patrol (a Firefox extension) in your browser?
yes, but my main browser is chrome (ff does poorly with nine windows and
60+ tabs). there is some sort of pinning, or at least discussion of it.
but it is not clear what is actually provided. and i don't see evidence
of churn reporting.
randy
Google uses certificate pinning for a very, very few sites. From http://blog.chromium.org/2011/06/new-chromium-security-features-june.html :
In addition in Chromium 13, only a very small subset of CAs have the
authority to vouch for Gmail (and the Google Accounts login page).
You can turn it on for other sites but:
Advanced users can enable stronger security for some web sites by
visiting the network internals page: chrome://net-internals/#hsts
You can now force HTTPS for any domain you want, and even “pin” that
domain so that only a more trusted subset of CAs are permitted to
identify that domain.
_It’s an exciting feature but we’d like to warn that it’s easy to break
things! We recommend that only experts experiment with net internals
settings._
Emphasis theirs.
The only Chrome browser I have lying around right now is on a Nexus 7 tablet;
I don't see any way to list the pinned certs from the browser. There is a
list at http://www.chromium.org/administrators/policy-list-3, and while I
don't know how current it is you'll notice a decided dearth of interesting
sites with the exceptions of paypal.com and lastpass.com.
--Steve Bellovin, https://www.cs.columbia.edu/~smb
The governments in question are watching for exfiltration and they
largely use a less risky approach: they issue their own root key and,
in most cases, install it in the government employees' browser before
handing them the machine.
A "reputable" SSL signer would have to get outed just once issuing a
government a resigning cert and they'd be kicked out of all the
browsers. They'd be awfully easy to catch.
Regards,
Bill Herrin
If push came to shove and minor legalities were not restraining me, I
recall (without checking) your domain's emails come to your home, and
your DSL or cable line is sniffable, so any of the CA who email URL
validators out could be trivially temporarily spoofed (until you read
your email and responded) by tapping your data lines. BGP games to
snarf your traffic are another venue, possibly not yet even covered by
wiretap laws that I know of, though I'm not currently an ISP in a
position to personally do that to you.
And none of this describes an extraordinary effort? The quote you're
trying to refute was, "suffer such attacks only with extraordinary
difficulty on the part of the attacker."
If you're going to argue that that's cheating, that IS the threat envelope...
You're quite right about the scope of the threat envelope. And it's
one to two orders of magnitude more difficult to penetrate than
man-in-the-middle with an unverified key.
Regards,
Bill Herrin
Yo William!
>
> Me, no, although I have read credible reports that otherwise reputable
SSL
> signers have issued MITM certs to governments for their filtering
firewalls.
That's not the case join is referring to.
The governments in question are watching for exfiltration and they
No, not really. Some are busy tracking "dissidents" among their populations.
largely use a less risky approach: they issue their own root key and,
in most cases, install it in the government employees' browser before
handing them the machine.
Not just for employees.
A "reputable" SSL signer would have to get outed just once issuing a
government a resigning cert and they'd be kicked out of all the
browsers. They'd be awfully easy to catch.
Oh! You mean like cyber trust and etilisat? Right... That's working just
perfectly...
Steven Bellovin writes:
The only Chrome browser I have lying around right now is on a Nexus 7 tablet;
I don't see any way to list the pinned certs from the browser. There is a
list at Policy List, and while I
don't know how current it is you'll notice a decided dearth of interesting
sites with the exceptions of paypal.com and lastpass.com.
You can see the current list of cert pins and HSTS preloads in the Chromium
source tree at
or
I believe Honest Achmed said it best:
"In any case by the time he's issued enough certificates he'll be regarded
as too big to fail by the browser vendors, so an expensive audit doesn't
really matter."
as well as
"Achmed's business plan is to sell a sufficiently large number of
certificates as quickly as possible in order to become too big to fail"
and
"Achmed guarantees that no certificate will be issued without payment having
been received, as per the old latin proverb "nil certificati sine lucre"."
- Matt
should have included this reference link:
<https://www.eff.org/deeplinks/2010/08/open-letter-verizon>
Hi Christopher,
That was nearly 30 months ago. At the time there were no reports of
fake Etilisat certs, merely concern that the UAE's regulatory
environment was "institutionally hostile to the existence and use of
secure cryptosystems." Has the EFF's SSL Observatory project detected
even one case of a fake certificate under Etilisat's trust chain since
then?
There's a reason Etilisat's cert is still valid and it isn't Honest Achmed's.
https://bugzilla.mozilla.org/show_bug.cgi?id=647959
Regards,
Bill Herrin
Thanks. The list is longer, but with the exception of Twitter (and possibly intuit -- a subdomain
is shown), not a lot more interesting. I don't see major banks, I don't see Facebook or Hotmail,
I don't see the big CAs, etc.
--Steve Bellovin, https://www.cs.columbia.edu/~smb
William Herrin wrote:
The governments in question are watching for exfiltration and they
largely use a less risky approach: they issue their own root key and,
That is a trusted first party.
Masataka Ohta
[snip]
It's ashame they've stuck with a hardcoded list of "Acceptable CAs"
for certain certificates; that would be very difficult to update. The
major banks, Facebook, Hotmail, etc, possibly have not made a
promise to anyone, that all their future new renewal certificates
will be from a specific CA; would be more interesting, if the Chrome
devs provided for a mechanism for making a remote query or receiving
a digitally signed "PINned cert list" download, that could be updated
dynamically, /and/ provided policy and mechanisms to have sites
included in the list.
One of the broken things about X500, is a certificate can only have
one signature.
The trust could be strengthened, if there were a mechanism allowing
multiple 3rd party attestations to be made (eg PGP-like multiple
signatures), or
a browser could be configured to only accept a certificate, if BOTH
(i) Signed by a CA, and
(ii) The certificate's information, or the CA information for the
cert is published in a 3rd party corroborating database, that also
requires proof of ID/authorization to publish in that DB.
(iii) And the server does the work of querying the 3rd party
databases listed by the client, by sending the CA ID, Certificate ID,
through a query to some standardized URL format, and returns the
timestamped digitally signed result (query answer, or affirmative
proof of no entry in the DB), during authentication, together with the
certificate.
Depending on the authenticating browser's config, a domain not found
in the 3rd party corroborating datasources, or listed by the 3rd
party source with an attestation level of "Only domain control
validated", might result in the CA's signature being ignored.
That is: the browser (or the user) should pick how strong the
certificate has to be, depending on the kind of business they will be
executing over the SSL channel.
CA's could later become required to check at least 2 3rd party
databases, to ensure any prior certificate issued by another CA was
actually revoked or expired, before allowing the signing of a new
certificate.
it's possible that the observatory won't see these in the wild, if the
observatory is on the wrong side of the connection. According to the
code EFF uses:
<https://git.eff.org/?p=observatory.git;a=blob;f=README;h=235117a992ff83b7c04c66ba928bc1907cf76944;hb=HEAD>
it looks like they simply portscanned 0/0 for tcp/443 listeners, then
grabbed certs from the respondents. In the cases we're talking about
in this thread EFF's observatory may never be in the middle of the
conversation.
In the cases of Etisalat (or one use they may have) the scanners may
not be behind etisalat's piece of gear which uses the CA cert in
question. "not observed in the wild" isn't really a good judge for
this particular problem I think 
As to why the Etisalat cert isn't yet removed, I wouldn't know... it
seems a bit fishy though.
-chris
To be fair though - if I was sitting on information of sufficient value that I
was a legitimate target for nation-state TLAs and similarly well funded
criminal organizations, I'd have to think long and hard whether I wanted to
vector my e-mails through Google. It isn't even the certificate management
issue - it's because if I was in fact the target of such attention, my threat
model had better well include "adversary attempts to use legal and extralegal
means to get at my data from within Google's infrastructure".
"Operation Aurora".
I probably fit into that description; while I vector my personal email
through Google, the actual sensitive stuff does not touch any wired or
wireless network. Because I know.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Google is setting a higher bar here, which may be sufficient to deter
a lot of bots and script kiddies for the next few years, but it's not
enough against nation-state or serious professional level attacks.To be fair though - if I was sitting on information of sufficient
value that I
was a legitimate target for nation-state TLAs and similarly well funded
criminal organizations, I'd have to think long and hard whether I
wanted to
vector my e-mails through Google. It isn't even the certificate management
issue - it's because if I was in fact the target of such attention, my
threat
model had better well include "adversary attempts to use legal and
extralegal
means to get at my data from within Google's infrastructure".
"Operation Aurora".
Well, the "bar" started at something as trivial as FireSheep. And I'm
sure many more silly (in retrospect) exploits remain to be discovered in
any cloud-based infrastructure (the bigger the cloud, the bigger the
target, the greater the potential damages/losses).
And a lot of infrastructure remains vulnerable to something as trivial
as FireSheep.
Jeff
[Full disclosure: I work at Google, though the opinions stated below are
mine alone.]
Aurora compromised at least 20 other companies, failed at its assumed
objective of seeing user data, and Google was the only organization to
notice, let alone have the guts to expose the attack [0]. And you're going
to hold that against them?
If you're the target of a state-sponsored attacker, Google is by far the
best place to host your mail. Good luck finding another provider that
enables SSL by default [1], offers 2-factor authentication [2], warns you
when you're being targeted by state-sponsored attackers [3], and actually
fights overly-broad subpoenas from governments [4].
While I'm writing, I'll also point out that the Diginotar hack which came
up in this discussion as an example of why CAs can't be trusted was
discovered due to a feature of Google's Chrome browser when a cert was
being used to spy on users in Iran [5]. Note that it also provides a good
example of the difficulty of getting away with such attacks.
[0] http://googleblog.blogspot.com/2010/01/new-approach-to-china.html
[1]
http://gmailblog.blogspot.com/2010/01/default-https-access-for-gmail.html
[2] http://support.google.com/accounts/bin/answer.py?hl=en&answer=180744
[3]
http://googleonlinesecurity.blogspot.com/2012/06/security-warnings-for-suspected-state.html
[4] http://www.google.com/transparencyreport/userdatarequests/
[5]
http://googleonlinesecurity.blogspot.com/2011/08/update-on-attempted-man-in-middle.html
Damian
I didn't say that. What I *said* was "one should *expect* a nation-state
adversary to go after your mail hosting company via multiple avenues of attack,
because it's already been tried before". Google is indeed one of the better
actors. But if you're a target, maybe it's time to reconsider whether the
phrase "hosting company" should be included in your environment *at all*.
Thanks for clarifying.
We're off-topic, but that decision needs to be weighed against the
alternatives. If your alternative is running your own mailserver at home,
then your risks are:
- They can come into your home and walk off with your machines. Even if
your hard drives are encrypted, your backups might not be... or maybe you
don't have backups?
- If you browse from the server they can get you with a trojan impacting
Flash or Java.
- Even if you don't browse from your mailserver they can try to
compromise it remotely if it's not fully patched. How good are you at
keeping your system patched. Does it fall a day or two behind when you're
on vacation?
- Speaking of vacation, how do you authenticate to your system? Does it
support 2-factor? Or maybe you don't think you need 2-factor because you
have an SSL cert. Did you self-sign it and tell your browser to ignore all
other CAs (to approximate Chrome's certificate pinning)?
- How does your email arrive/leave? They could be tapping your line...
or they could just DoS you off the net.
If you really think you can get all of that right, all the time, then I
wish you the best of luck. But remembering that most targets are not
cypherpunks, telling them to do it themselves is incredibly bad advice.
Back on topic: encryption without knowing who you're talking to is worse
than useless (hence no self-signed certs which provide a false sense of
security), and there are usability difficulties with exposing strong
security to the average user (asking users to generate and upload a
self-signed cert would be a customer-support disaster, not to mention all
the outages that would occur when those certs expired). Real-world
security is all about finding a reasonable balance and adapting to the
current threats.
Damian