0

I'm writing a Chrome packaged app for diagnosing web services. I want to be able to send a GET request to a URL and look at the headers and data in the response.

My problem is if a users visits a site that has the HSTS header set before using my app, my app will then be unable send GET requests to the http:// URLs for that domain because Chrome will automatically convert the http:// URLs to https:// ones before the request is sent out.

Is there anything at all I can do to prevent this? I've looked into the webrequest API and webview tag but I'm finding nothing that lets me ignore HSTS.

Is it possible to use https://developer.chrome.com/apps/sockets_tcp for this (I would need to be able to support http, https and gzipped data)?

hvrpn
  • 41
  • 2

1 Answers1

0

Is there anything at all I can do to prevent this?

Probably not. If you already tested <webview> and it shares the HSTS list with the browser, then the network layer will transparently rewrite this for you.

Is it possible to use chrome.sockets.tcp for this?

Technically, yes, HSTS shouldn't matter for that. Practically, you would need to implement something like wget+SSL+gzip from ground up (in JS, NaCl or a Native Host - but in the latter case you don't really need built-in sockets).

Xan
  • 74,770
  • 16
  • 179
  • 206
  • So in your view, in practice it really isn't possible then (without basically implementing wget yourself inside Chrome which would be a huge amount of work)? Are there any existing NaCI or Native Host libraries that do something like this? – hvrpn Jul 09 '16 at 11:16
  • I didn't really look into existence of such libraries for NaCl; [Native Messaging](https://developer.chrome.com/extensions/nativeMessaging) allows you to _actually_ call `wget` or equivalent, for instance, but it's an unwieldy big hammer. Unfortunately (or fortunately?) HSTS is baked into the Chrome platform, which provides the runtime for Chrome Apps. Maybe you should look for alternative app frameworks (Electron? Node-WebKit? Needs research). – Xan Jul 09 '16 at 11:19