semenko

Chrome does do pinning, but ignores pins when the cert parent is a privately installed cert (because this is a "feature" used by many enterprises).

"""

Chrome does not perform pin validation when the certificate chain chains up to a private trust anchor.

A key result of this policy is that private trust anchors can be used to proxy (or MITM) connections, even to pinned sites.

'Data loss prevention' appliances, firewalls, content filters, and malware can use this feature to defeat the protections of key pinning.

"""

See: http://www.chromium.org/Home/chromium-security/security-faq#...

Details via: https://securelist.com/blog/research/67962/the-penquin-turla...

Notably, the C&C domain has been sinkholed by Kaspersky.

This has been linked to the complex "Turla" industrial espionage malware, as it shares a C&C server. (Turla: http://securelist.com/analysis/publications/65545/the-epic-t... )

They buried the lede a bit -- since I doubt organized attackers are after the personal information of postal service employees:

"It is also possible that the Chinese were after other types of data, analysts said. For instance, the U.S. Postal Service, at the request of law enforcement officials, takes pictures of all addressing information from envelopes and parcels.​"

http://www.nytimes.com/2013/07/04/us/monitoring-of-snail-mai...

For Google domains, this is handled by an internal Chrome extension called "cryptotoken". See, e.g. https://chromium.googlesource.com/chromium/src.git/+/master/...

For all other domains, there's an open-source, pre-release Chrome extension that handles the site<->token handshakes: https://github.com/google/u2f-ref-code

No one has mentioned the coolest feature of U2F/Fido auth: TLS Channel IDs.

Via an internal Chrome extension ("cryptotoken"), authentication state & the handshake can be bound to a specific TLS session -- preventing cookie theft. Incredibly cool: http://www.browserauth.net/channel-bound-cookies

Yeah, it looks like more reasonably priced U2F/FIDO tokens are coming soon, probably to the Play Store.

Behind the scenes, the auth layer in Chrome is handled by a sneaky extension. There's a huge listing of product IDs in the manifest, all likely to launch very soon: https://chromium.googlesource.com/chromium/src.git/+/master/...

(And some explicit Play Store references: https://chromium.googlesource.com/chromium/src.git/+/c6b104c... )

Ah, it looks like their FAQ also says this is supported:

   Can I use the same Security Key with multiple Google Accounts?
   Yes. You can register the same Security Key with multiple Google Accounts.

https://support.google.com/accounts/answer/6103543?hl=en

The next release of ChromeOS will include nearby/proximity unlock features integrated with Android L, which they're calling "Easy Unlock".

There are a few somewhat-spammy blog summaries, e.g. http://www.omgchrome.com/chrome-os-smartphone-easy-unlock-fe...

EDIT: Looks like this is now working! Looks like there is a tiny UI bug -- make sure your account is correctly selected on the Security Token page if you have multiple accounts signed in. #userError

Ouch, looks like a serious downside is that a given key can only be used with one Google account.

Trying to add a U2F-compatible token to more than one Google account results in errors: "This Security Key is already registered. Use a key that is not registered yet and try again."

Seems a little unlikely, given Ksplice's patents (now Oracle's patents) covering the area.

From an older post @ https://news.ycombinator.com/item?id=2791756

The first is "Method of finding a safe time to modify code of a running computer program": http://bit.ly/ksplice-1

The second is "Method of determining which computer program functions are changed by an arbitrary source code modification": http://bit.ly/ksplice-2

Cool! I wrote a similar extension for Chrome that simply enforces a user-adjustable maximum cookie lifetime (e.g. 21 days instead of 10+ years...). This seems to provide a good balance for login cookies that you don't necessarily want removed every session.

https://github.com/semenko/chrome-limit-cookie-lifetime

https://chrome.google.com/webstore/detail/limit-cookie-lifet...

(And the same for Chrome's ever-present history:

https://github.com/semenko/chrome-limit-history-lifetime

https://chrome.google.com/webstore/detail/limit-history-life... )

ErrataSec, at least (their IPs are implicated in the logs) says this is a false-positive generated by the minimalist SSL implementation in masscan:

http://blog.erratasec.com/2014/04/no-we-werent-scanning-for-...

Surprised no one's used this opportunity to talk about Google's gnubby / FIDO / U2F plans.

Non-phishable two-factor auth token: http://fidoalliance.org/

See presentation: https://docs.google.com/a/google.com/presentation/d/16mB3Npt...

They get an A from Qualys (yay?): https://www.ssllabs.com/ssltest/analyze.html?d=bing.com

… but no PFS :/

The PCB they show (https://s3.amazonaws.com/ksr/assets/000/935/465/b197830112a2...)

… has the model number (S2122B) of the SmartQ Z3 watch, too. http://forum.xda-developers.com/showthread.php?t=2501598

IIRC, Twitter is also concerned about this, and recently proposed a hash-based validation for externally included resources (though I can't seem to find their proposal right now …).

The co-author of the study (Ridker) and the Brigham have already issued a Press Release disputing the reporter's spin.

Ridker portrays the calculator issues as minor, and offers strong support for statins in risk reduction (which is what the data /strongly/ support):

http://www.brighamandwomens.org/about_bwh/publicaffairs/news...

(That's his name.)

Nothing says reassuring quite like "supports WiFi" but also "WEP only" http://www.accessdata.fda.gov/cdrh_docs/pdf8/P080009c.pdf [pg. 101, section 5-21]

The HSTS commits /maybe/ suggest that Google thinks a Verisign intermediate was signing MITMs for Google properties. They just blacklisted "VeriSignClass3SSPIntermediateCA"

See: https://chromiumcodereview.appspot.com/23523051

Note that the associated bug is private (https://code.google.com/p/chromium/issues/detail?id=173460).

There's a good explanation of the "bad_static_spki_hashes" parameter here: http://ritter.vg/blog-cas_and_pinning.html

Sure, though there are simhash implementations, where you can compute a hash that itself can be used to compute a hamming distance between two inputs.

(This is used a fair amount in search, to cluster similar documents.)

Sure, but the Times piece /very strongly/ suggests it: http://bits.blogs.nytimes.com/2013/09/10/government-announce...

(Perlroth quotes from a few unpublished, leaked memos.)

The NYT piece today had different redactions than the Guardian, showing the NSA may have done this with commercial VPN ASICs.

The Times includes "Complete enabling for [XXXXXXX] encryption chips used in Virtual Private Network and Web encryption devices." http://www.nytimes.com/interactive/2013/09/05/us/documents-r...

(compare to http://www.theguardian.com/world/interactive/2013/sep/05/sig... )

And a similar tweet: (WARNING / CRASH) https://twitter.com/daken_/status/303784082599456768

Well, luckily, Twitter's domains & cert are added to the Chrome HSTS pins list, so Chrome should just serve a scary security error.

Looks like their WHOIS data has reverted to normal. Not sure the NS records ever changed (though the contact data did).

Perhaps more critically, twimg.com (and now Twitter, it seems) has also been compromised. Both share the MelbourneIT registrar.

$ whois -h whois.melbourneit.com twitter.com -> now owned by sea@sea.sy (Syrian Electronic Army)

The name servers for the Times have been switching back-and-forth for a while. I've chronicled most of it at https://twitter.com/semenko

Reminds me of the IPv6 "Type 0" routing header disaster, where you could store data in routing loops.

See, e.g. slide 30 of: http://www.secdev.org/conf/IPv6_RH_security-csw07.pdf

They clearly mention this goal in their blog post:

http://blog.wikimedia.org/2013/08/01/future-https-wikimedia-...

(Keep in mind these slides are 5 years old, before Google Search over SSL)

The NSA has clearly tapped trans-oceanic fiber -- why not also tap high-volume inter-datacenter links?

> edit: Gmail messages must only be captured when they leave the Google network.

It seems easier for the NSA to tap datacenter <-> datacenter fiber links inside Google's network.

Why worry about decryption when you can have Google's frontend servers do it for you?