Hacker News Reader

Comment by devalnor | Hacker News Reader

Very nice service but how do you manage the CDN subresource integrity (SRI) if the packages are different for each individual user?

It's possible to check subresource with es6 module but only if you know the signature first.(https://stackoverflow.com/questions/45804660/is-it-possible-...).

Even Webpack will not handle it with webpack-subresource-integrity (https://www.npmjs.com/package/webpack-subresource-integrity)

Of course HTTPS is strong but not a foolproof solution against man-in-the-middle attack.

View on HN

SRI doesn't really protect against man-in-the-middle. They protect against somebody having access to manipulate the data on the CDN or a malicious CDN.

If an attacker is in a position to be man-in-the-middle and can already get around HTTPS, they might as well compromise the page loading those resources.

If you serve your start page yourself, or via a different cdn - then Sri would protect against malicious code from other cdns such as pika.

If, say, you serve example.com from one source, and link js via pika.cdn - then if pika is compromised, your site would be too. If using sri, the example.com infrastructure would have to be subverted.

All things being equal, mitm ssl or subverting a well run cdn is hard - but if you double the number of cdns in play, you make compromise of one of them twice as likely/easy. With sri, you get to keep your single point of compromise - but can leverage the benefit of a besboke cdn for your js. If any.

I could probably google this but I'm not well versed in security stuff. What would a MITM attack against HTTPS look like?

Not sure if it can be considered a MITM attack, but without subresource integrity the developers have to blindly trust the Pika CDN to host the same script file on that URL.

SRI might be impossible to implement in this case, not only because of the Differential Serving feature but the fact, based on their examples, that developers should link to the major versions of projects, which would mean that the content under the URL will change.

This is where a reliable IPFS-like CDN would shine.

There would be a number of ways to do this:

- Strip SSL by for instance blocking port 443 and hoping they fall back to HTTP.

- Get your own root certificate installed on the equipment of the user you are attacking. This is fairly common in corporate environments for instance.

- MD5 collision attacks (although almost every certificate would be SHA signed these days)

HSTS prevents the first of these if the client has connected to the server previously.

Chrome also hasn't trusted certs with MD5 since version 65.

HSTS Preload prevents that from happening even if they never visited the site

Reply on news.ycombinator.com