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.
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.
- 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)
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.