3 ms·
> Users/user agents need to know whether to expect a connection to be secure. Why not expect it to be secure? Connect to https before http.
by noja 10y ago
> Users/user agents need to know whether to expect a connection to be secure.
Why not expect it to be secure? Connect to https before http.
- markild 10y agoBehavior like that needs to come with a huge warning label. It would be trivial for any man-in-the-middle to block https and server http.
- AstralStorm 10y agoThis is exactly why browsers warn about such redirects. That said, this reminds me of a similar discussion on mail servers. There, STARTTLS sees much more use. The main problem is preventing downgrade attacks. With mail it is easy to just remember the setting for every server. Not so with websites.
- michaelt 10y agoI've seen quite a bit of criticism of it for mail servers [1] because an attacker can simply block the 'STARTTLS' message and (many) clients will silently accept that. [1] https://www.agwa.name/blog/post/starttls_considered_harmful https://www.agwa.name/blog/post/starttls_considered_harmful
- hello_there 10y agoThey could display that same "this page is not secure"-page that they display on broken certificates.
- chrisseaton 10y agoI'm not sure you can assume that the same URL with https will be the same content as at http. It could be an entirely different site that you may not have wanted.
- ATsch 10y agowhat if you block the https request in some way? You can now force an Insecure connection.
- nateguchi 10y agoA good solution for HTTP sites is to load the https version after first loading over http. If they have similar content, show a bar at the top of the browser with a message along the lines of "A secure connection is possible, click here to go to use the secure version of this page". Then it would be good to remember this setting and always pull the HTTPS.
- ukblewis 10y agoThat isn't really viable yet. Browser vendors could decide that they will introduce this functionality in a few years though. IMHO, the feature would need to be implemented as some have suggested, by enabling any website to transmit securely or insecurely, but for the web browser to request a secure TLS connection first (trying HTTP and HTTPS to reduce incompatibilities) and if a website appeared to have issues, then try insecure connections. If an insecure page were to be served, the browser should indicate this with a broken padlock. Furthermore, I believe that browsers should warn when any data is input, e.g. clicking items that cause JS calls or text is typed - this strict implementation is important. Single page JS applications have made it possible to send any input data via JSON, we cannot only warn the user on a form submission, since it would be very possible to capture details via AJAX. E.g. If I were impersonating an e-commerce solution, I could hope the user would not notice the padlock and use AJAX to send the data preventing any form submission warnings. This would be annoying for users when they were using such websites regularly, but this would be a good thing - pressuring websites that handle user inputs to act responsibly and use encryption via TLS.