steps: 1. load https://www.google.com:80/ 2. read the whole error message actual results: Secure Connection Failed An error occurred during a connection to www.google.com:80. SSL received a record that exceeded the maximum permissible length. (Error code: ssl_error_rx_record_too_long) The page you are trying to view can not be shown because the authenticity of the received data could not be verified. * Please contact the web site owners to inform them of this problem. The problematic section is this: The page you are trying to view can not be shown because the authenticity of the received data could not be verified. I don't think ssl_error_rx_record_too_long relates to the authenticity of the received data. I'm mostly filing this bug to watch the flow of psm/docshell error reporting because I'd like to change some other page in this space and don't quite understand how these items connect.
This is either https://www.google.com:80. (plain text on https) or http://www.google.com:443/ (plain text over port 443).
for the latter, i get: Connection Interrupted The connection to the server was reset while the page was loading. The network link was interrupted while negotiating a connection. Please try again. Which given the fact that we probably could detect it's not going to work does deserve a bug and a better error message. But I think that's a different bug, since at least, for me, it's not the same error code.
Please specify in more clarity what exactly you are proposing.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 10 years ago
Resolution: --- → INVALID
remove the section about authenticity: | The page you are trying to view can not be | shown because the authenticity of the | received data could not be verified. possibly also add a section indicating that the server is misconfigured (an http server talking to an https port). preferably linking to a faq page which explains this.
Status: RESOLVED → UNCONFIRMED
Resolution: INVALID → ---
(this was once before filed as bug 384866, but it was duped into a black hole, i'd like this fixed independently and sooner)
Mass change owner of unconfirmed "Core:Security UI/PSM/SMime" bugs to nobody. Search for kaie-20100607-unconfirmed-nobody
Assignee: kaie → nobody
1. Try to connect to an HTTP server using the HTTPS protocol, e.g. https://mozilla.org:80/ Result: "An error occurred during a connection to .... SSL received a record that exceeded the maximum permissible length. (Error code: ssl_error_rx_record_too_long)" Expected: A more specific error message should be shown, so users can diagnose the problem correctly and so web site admins can fix it more quickly. (For example, https://www.popehat.com/ is currently misconfigured, and even crypto experts are confused: https://twitter.com/taoeffect/status/585175741588865025) (Bug 936850 comment 0 explains why parsing the bytes of "HTTP/1.1" as a record header results in this error message.)
Status: UNCONFIRMED → NEW
Ever confirmed: true
Summary: details for ssl_error_rx_record_too_long are wrong → Show a more specific error message than "ssl_error_rx_record_too_long" when we get an HTTP response
Component: Security: UI → Security: PSM
Priority: -- → P3
Whiteboard: [psm-feedback] → [psm-feedback][psm-backlog]
yes, i´d second that. please ! i had problems with ssl configuration today and fiddled for more then 2 hours to find the reason. if firefox would not have given that stupid message, i would have fixed that problem much more quickly. (i found in apache, a vhost on port 443 may talk http if the order configuration files being read is not correct - and while you expect that you connect to a https port and get this weird warning, you never guess that it`s being caused because that port incorrectly talks http) it`s even worse if you are in a non-standard environment with http or https being on ports besides 80/443. and in development environment, this is the case very very often. so please don`t spit out such misleading ssl handshake message where simple http plaintext communication can take place it`s not only about users typing a url wrong. it`s also admins do wrong configuration or involved persons make an error when forwarding an url via email.
I'm also seeing this on transmission's http interface. It runs on port 9091 and fails to prompt me for winauth (which works in every other browser), but Firefox force switches me to https and then fails with SSL_ERROR_RX_RECORD_TOO_LONG.
You need to log in before you can comment on or make changes to this bug.