Moderator: trava90
Code: Select all
Secure Connection Failed
An error occurred during a connection to [redacted].
The OCSP response contains out-of-date information.
(Error code: SEC_ERROR_OCSP_OLD_RESPONSE)
The page you are trying to view cannot be shown because the authenticity of the received data could not be verified.
Please contact the website owners to inform them of this problem.Well your course of action is to contact this redacted site who are likely running old web server software with this flaw, and to have them update to a fixed version.Stargate38 wrote:site has been redacted for privacy reasons
It's stated for a reason.Please contact the website owners to inform them of this problem.
Using something else is not user freedom provided by the software being dumbed down. User freedom is about how to use something, not simply the possibility of using something or not using something. User freedom is when you can disable ESP in your car to drift around - which is of course dangerous if you don't know what you're doing. What you're talking about is the possibility of buying another car that has no ESP. Which is nonsense.New Tobin Paradigm wrote:as a user, have the freedom to use something else in this case
Originally we were talking about a preference that can only be turned on via about:config. There is at least one warning message that tells the user that it's not recommended to tinker with those options. If a user doesn't know what the OCSP warning means, he will have to find out. Then he will learn about why it's there during the process of finding the right solution to make it disabled in about:config. You should not optimize a software product for dumb, ignorant users by even removing the fallback options for advanced users. By the way, the developer should consider implementing an option into the already existing security exception framework by enabling old OCSP responses for individual hosts only.New Tobin Paradigm wrote:A user to bypass and disable them and leave them disabled forever because the USER does not bother to learn why they shouldn't disable a security feature.
First, Pale Moon comes with no warranty and it's accepted by the end-user upon installation. Second, you warn the user at least twice. First time when he goes to a site with outdated SSL configured. Second when he goes to about:config.New Tobin Paradigm wrote:THEN they run into problems of their own doing and blame us
How often do you encounter such situations?palacs wrote:It should be a warning like the one we display for an expired certificate, which the user should be able to bypass by adding an exception.
I don't know much about OP's specific situation but has it actually happened that someone blamed you for his own decision? If an user decided to turn off a security feature while knowing what it does, and still complains, then just tell him off. Hopefully PM won't go the road Firefox did...New Tobin Paradigm wrote:The merit of the preference at this point is debatable.. As for your "User Freedom" you, as a user, have the freedom to use something else in this case. What a ridiculous argument. Cause guess what security bypassing preferences allow? A user to bypass and disable them and leave them disabled forever because the USER does not bother to learn why they shouldn't disable a security feature. THEN they run into problems of their own doing and blame us while others throw the insecure label at us because something is possible but not recommended.
So you can take your now invalidated argument somewhere else and cry to them when you don't get your way.
Even if the users themselves might not complain, there is a consistent faction whose aim is to discredit Pale Moon for whatever reason.Kingpin wrote: I don't know much about OP's specific situation but has it actually happened that someone blamed you for his own decision? If an user decided to turn off a security feature while knowing what it does, and still complains, then just tell him off. Hopefully PM won't go the road Firefox did...
Try this: When you encounter a situation like this, imagine the developer(s) getting in your face and screaming "Not with MY browser you won't!"palacs wrote:With this attitude you are not contributing to anyone's security. You are just simply destroying user freedom.
Solution: Accept that the developer(s) are not going to accommodate you. So, let's see: Their current/future software won't do what you need. But...wait...their previous one(s) did, right? So, do what I do: Grab a copy of those old versions and use them just for what doesn't work in the current one. Most can be used side by side with your main "locked down and sealed for your protection" version.palacs wrote:There are many situations where one may need to bypass a security warning like this, for example testing, using legacy products on a secured internal network that can't be upgraded, or just simply the need of some download from a site with an unreachable webmaster.
Where do the quotes in that thread come from? Anyway, that some people whine isn't a problem. That's something every software in the world suffers from. And I doubt a "rumor control" will prevent them.vannilla wrote: Even if the users themselves might not complain, there is a consistent faction whose aim is to discredit Pale Moon for whatever reason.
So a situation like that is enough for them to start a defamation campaign.
Why do you think Moonchild had to write viewtopic.php?f=4&t=21626 otherwise?
I know the reason to not have that preference is stronger than public relationship, but still.
Bypassing this would make the browser non-compliant with one of the core RFCs for secure internet traffic (TLS extensions).Clients requesting an OCSP response and receiving an OCSP response in
a "CertificateStatus" message MUST check the OCSP response and abort
the handshake if the response is not satisfactory with
bad_certificate_status_response(113) alert. This alert is always
fatal.
