Comment by mananaysiempre | Hacker News Reader

Comment by mananaysiempre | Hacker News Reader

There seems to be some degree of overcounting in the reported figures: the number of “hosts” is the number of unique hostnames in the table, but the number of “IPs” is a straightforward sum of IP address counts that the table segregates by service, and I refuse to believe that (e.g.) the IP address of login.live.com as resolved by OneDrive is always different from same as resolved by Skype.

  $ curl -fsSL 'https://helgeklein.com/blog/windows-os-services-apps-network-connection-target-hosts/' | pup 'td:nth-child(5)' text{} | sed 's/:.*$//' | sort -u | wc -l
  291
  $ curl -fsSL 'https://helgeklein.com/blog/windows-os-services-apps-network-connection-target-hosts/' | pup 'td:nth-child(4)' text{} | awk '{ s += $1 } END { print s }'
  2764

There’s also a fair amount of infrastructural stuff such as DigiCert’s OCSP service, and every shard(?) in the Windows Update, OneDrive, etc. CDNs is counted as a separate hostname.

Not that I’m happy about of any of these connections, but the report looks much less interesting than the totals alone suggest.

> DigiCert’s OCSP service

A weakness of the OCSP protocol is that it gets sent the certificate hash as an input. This means that to a significant degree, an OCSP provider can track what software you are using, what sites you visit, etc... For the code signing certificates, they could also determine which year (or two) it came from.

DigiCert could sell that to marketing companies, and spy agencies / state-sponsored hacking groups could use it to determine if you are running vulnerable versions of software they have hacks for.

There would be ways to fix the protocol to be less vulnerable to this, but I'm sure you'll find that any such suggestion would be rejected by the major players like DigiCert in a strangely forceful manner.

OCSP is indeed broken in many ways.

On the bright side, with the ca/browser forum limiting the max length of a certificate to about a year it would be pretty easy to just use a single revocation list. A CRL 2.0 so to say. Just like the browser downloads the Google safe browsing list.

EDIT: Just to be clear; With CRL 2.0 I don't mean blockchain...

OCSP is done over plain HTTP (for obvious reasons), so the OCSP provider doesn’t have exclusive access to this data. There is not much value there for DigiCert and others when every ISP can potentially sell the same data.

OCSP stapling helps maintain privacy, so eg. ESNI isn’t completely pointless when stapling is used.

>OCSP is done over plain HTTP (for obvious reasons)

It's not obvious to me. Why can't it be done over HTTPS? From what I can tell nothing stops you from doing that.

If OCSP was done over HTTPS, you'd end up with an infinite loop - you'd have to do an OCSP query to check that the OCSP server's certificate is not revoked, and so on.

Sure HTTPS wouldn't help if an attacker had the cert for the OCSP server, but I feel like that is rare to happen compared to other certs being revoked and I believe there are privacy / anticensorship benefits you ran get from https.

To me it seems simple to just skip an OSCP check compared to having to use HTTP.

i think because what is asked for is a list of revoked certs, and the connection being used could be already on that blacklist. the list must available without the involvement of what is being checked.

That's not what OCSP is. OCSP just lets you query the status of a cert.

What sort of logic is that. "This data isn't private because we just broadcast it to the entire internet on your behalf" doesn't strike me as a valid argument against considering privacy.

If it is I'm going to use this way more in all the compliance meetings I attend. Oh, you're worried about the secrecy of all this proprietary private information we're holding? Don't worry, I'll just wrap it in a torrent, broadcast it to the DHT, and _now_ it's no longer private, so the secrecy doesn't matter.

There is actually now a dormant but a powerful system that's a win-win to privacy and CA's infra bills: OCSP stapling (and the associated must-staple directive). Instead of the client requesting OCSP validation directly, the web server does that on behalf of its visitors. This saves on CAs since that the web server can minimise the request to every minute (or even every half-hour if that's what the website operator desires) and is definitely a win for privacy (as users will no longer be required to send a request to the CAs). The only probable downside is that revocations aren't instant, but in theory you could arrange your CA to issue 5-minute validity OCSP responses allowing for faster revocation.

Now if this exists, why aren't people switching to this? Google. Chrome doesn't even actively validate revocation information anymore, and Android didn't even bothered to do many of the required validation since practically its inception (so much that Let's Encrypt exploited that fact to allow their CA to still issue valid certificates to older Android devices: https://letsencrypt.org/2020/12/21/extending-android-compati...). Since Google insists that revocation is broken (as demonstrated though it can be fixed now if we want to) no-one (at least at a corporate level) is seriously pushing OCSP must-staple.

P.S. you should at least read GRC's post about CRLSets (the only mechanism available in Chrome) that was posted in 2014 a few days after the Heartbleed discovery (https://www.grc.com/revocation/crlsets.htm). It's still (unfortunately) relevant today, amd says a lot about Google's security practices.

> I refuse to believe that (e.g.) the IP address of login.live.com as resolved by OneDrive is always different from same as resolved by Skype.

I could believe that, actually. There are reasons you might want to always host different services on non-overlapping IPs -- DDoS mitigation, traffic prioritization, service isolation, limiting impact of unscrupulous ISP / government content blocks...

I don't think that the exact problem is double counting IP addresses or multiple CDN shards that are basically the same but there are several concerning things:

1) Why would relatively specific services need to contact so many different endpoints? The skype service is using about 40 different endpoints by the look of it. 2) Why can't the providers of these services use much more consistent naming? I am less concerned about pipe.skype.com and avatar.skype.com being called from skype because it makes sense. On the other hand, calling b-ring.msedge.net is weird. What is that site? Could be MS, could be anything. 3) It is not clear whether these services were expected to be enabled or not. For example, I don't like the idea that Windows is wasting internet bandwidth on Cortana or XBox live since I use neither of them.

> I refuse to believe that (e.g.) the IP address of login.live.com as resolved by OneDrive is always different from same as resolved by Skype.

Do you have a reason to doubt either the sincerity or technical ability of the Author? Did you find a fault in their methods?

I totally believe it, both from a load balancing perspective and from a stack perspective.

There was a version of Mac OS were different applications used different resolvers so, for instance, changing /etc/hosts would redirect SOME services/browsers to the IP in /etc/hosts and other services/browsers would still use DNS. I've had similar issues manually setting the DNS server address where some services ignored the setting if they could resolve against Apple's favoured DNS. This might still be true but I'm now longer doing security work and I'm not using these tricks anymore.

Reply on news.ycombinator.com