4 ms·
How many new servers are going to be needed now that https is used for everything and requests can't be cached? The main thing holding us back there are browse
by pmjordan 16y ago
How many new servers are going to be needed now that https is used for everything and requests can't be cached?
The main thing holding us back there are browsers that go apeshit if you load images via HTTP on an HTTPS page. Requiring JavaScript or other active content to be loaded from the same HTTPS server would be a good thing in many cases. I think currently ANY https server is allowed, which doesn't actually defend against any kind of XSS, so it's pretty meh. Or is there some kind of meta tag etc. that enforces same-origin? (If not, that would be a cool addition. Maybe a list of allowed domains?)
- timcraft 16y agohttp://stackoverflow.com/questions/954327/hidden-features-of-html/960111#960111 http://stackoverflow.com/questions/954327/hidden-features-of...
- pmjordan 16y agoThat will still load images via https, not http. They'll still be cached client-side of course, but they can't be cached by proxies and you need an SSL certificate for your static content server.
- jdunck 16y agoFWIW, non-JS is still a vector. For example, img tags can stomp on cookies. Yes, serving static media over SSL is diminishing returns, and it would suck for mid-stream proxies (and every ISP will hurt from it). But don't argue that it doesn't matter from a security perspective.
- pmjordan 16y agoWhen done correctly, it should at least avoid this sort of cookie stealing scenario, though - HTTPS-only cookies won't leak into HTTP requests for non-active content, though malicious Set-Cookie: injection into the HTTP responses can obviously log the user out, etc. and may even reveal unwanted info if the HTTPS server doesn't handle the situation gracefully.