Unrecognized certificate authority dialog presented twice upon cancel

VERIFIED FIXED in Future

Status

P3
normal
VERIFIED FIXED
17 years ago
2 years ago

People

(Reporter: ssaux, Assigned: kaie)

Tracking

1.0 Branch
Future
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(3 attachments)

(Reporter)

Description

17 years ago
Visit above url. Presented with the dialog, click cancel. The dialog is
presented again. Clicking cancel again sets the url box to above URL but results
in blank page.

Choosing "do not accept this cert... do not connect..." radio button then "ok"
exhibits exactly the same behavior.

Expected behavior in both these instances is to stay on the current page.

Same faulty behavior with expired server certs:
https://bolohead.mcom.com:23168/ciphers.html

May warrant two bugs, but the behavior is so strickingly similar, I prefer to
lump them together.
(Reporter)

Comment 1

17 years ago
P2
target 2.1
Priority: -- → P2
Target Milestone: --- → 2.1
(Reporter)

Updated

17 years ago
Keywords: nsenterprise

Comment 2

17 years ago
*** Bug 75594 has been marked as a duplicate of this bug. ***
(Reporter)

Comment 4

17 years ago
P1
Priority: P2 → P1

Updated

17 years ago
OS: Linux → All
Hardware: PC → All

Comment 5

17 years ago
Why is there a cancel button here at all?  Isn't the third option ("Do not
accept this certificate and do not connect to this web site") the same thing? 
If it's the same thing (which I'll bet it is since selecting this third option
makes you go through that window two times, just like "cancel") we should delete it.

Also, I don't know if I'd make this a P1 bug.  This is an exception case (where
the CA isn't known), and it's the least chosen of the three selections.  I'd bet
most of the time people click the button to accept the cert just for this session.
I'd probably put this at a P3 (or later it) myself unless people know of real
deployments where this bug would produce problems.
I would say that cancel is there so people who just want to abort the action
they just took that caused the dialog to appear don't have to read the whole
thing and then pick the right option just to get the thing to go away...

Comment 7

17 years ago
Seeing how you are arguing about the UI, I thought it might be good to know 
that I am redesigning this dialog according to a mpt-spec: bug 91466
(Reporter)

Updated

17 years ago
Priority: P1 → P3
(Reporter)

Updated

17 years ago
Keywords: nsenterprise

Comment 8

17 years ago
Mass assigning QA to ckritzer.
QA Contact: junruh → ckritzer
*** Bug 94389 has been marked as a duplicate of this bug. ***
moving keyword from bug 94389
Keywords: topembed

Comment 11

17 years ago
This problem occurs only if user selects both "Enable SSL Version 3"  
and "Enable TLS" options under preferences->privacy and security>SSL. If you 
select either "Enable SSL Version 3" or "Enable TLS" option this problem goes 
away. 

Comment 12

17 years ago
Created attachment 45681 [details] [diff] [review]
Handling "Cancel" option

Comment 13

17 years ago
Problem is when user selects the cancel button mozilla thinks that server does 
not conform to SSL specs and it will try TLS. I attached a fix for this. This 
patch will also fix problem when user selects "Do not accept this cert" option 
(bugscape bug: 8209)
Created attachment 45911 [details] [diff] [review]
The above whole file as a patch
Sudheer, I assume the file you posted was from MOZILLA_0_9_2_BRANCH? Here it is
in patch form.
I tested the patch here against both 0.9.2 and the current (as of this morning)
trunk. It works. I think some more work should be done here though. The problem
is a method which just returns a boolean for success or failure. If the user
cancels, all it can do is return PR_FALSE and the caller has no way of knowing
what happened. What we should do is make the method return an nsresult, return
NS_ERROR_USER_CANCELED (which may not exist but needs to), and then the caling
code would know not to try again.
(Reporter)

Comment 17

17 years ago
reassigning to kai to follow through.
->kai
Assignee: ddrinan → kai.engert
Keywords: patch, review

Comment 18

17 years ago
looks like we have the patch, can it get on the 9_2 branch ?

Comment 19

17 years ago
Although this patch seems to work, it is not yet perfect, but introduces other
regressions.

For example, if you are connecting to an unknown CA, the user will never get
informed about any SSL errors that might appear during the session.

In addition, if a site is indeed not TLS tolerant, this patch will stop the
Browser from automatically retrying with older SSL.

I vote against taking this patch. I agree with solution suggested by Conrad,
hence, this patch has not yet been written.

I can't decide whether this patch should go into the 0.9.2 branch or not, but
for the trunk, I'd prefer Conrad's suggestion.

Removing patch and review keywords.
Keywords: patch, review

Comment 20

17 years ago
The code in this patch runs only when user is presented a dialog box. This 
patch keep track of the user's action. If user selects "Cancel" option it would 
not let mozilla try on TLS/SSL even if there are errors ( this dialog box 
should be shown only if SSL/TLS  connection is OK) because user does want to 
continue. SSL/TLS errors will occurs before presenting this dialog box. If 
server is not SSL compliant you won't the see the dialog box anyway and than 
mozilla will try the TLS( or will follow the same logic whatever it does now). 
In my opinion if user selects cancel you do not need to try TLS or old SSL. 
However if you are presenting a dialog box while there are known SSL/TLS 
problem that would be another mozilla bug. This patch seems to work fine for me.

Comment 21

17 years ago
1) You are right regarding TLS/SSL. The error message is not displayed until
both sides have established a working connection, therefore your bug doesn't
prevent fallback to the old protocol, I was wrong.

2) I want to talk about the data transfer that happens after the handshake is
finished.

If the handshake is finished, but later during the transfer an error occurs, the
browser should show an error message.

With your patch you completely disable error message reporting to the user, once
you have displayed the unknown CA message.

3) I found a different problem. Go to https://kuix.de/ca . This has two
problems. First, you will normally not have the CA for the used certificate.
Second, the certificate doesn't match the host name.

While this page loads fine without your patch, it doesn't work with your patch!
I have not yet understood why this happens.

Comment 22

17 years ago
what's the current status of this work? will it land anytime soon?

Comment 23

17 years ago
I made a quick peek into this. As I added some state about "the last reported
error to the user" in a patch to bug 96024, I thought I could add some few lines
that would fix this bug.

However, it seems that some parts of Mozilla initiate a complete retry of the
transaction. And in that case I don't have an obvious instance avaialble, where
the state "already warned" could be added.

It seems that the http protocol layer it initiating the retry. This is the real
error we should prevent, maybe by returning a better return code.

I'm attaching a log.

There are open PSM bugs with higher priority, not sure when this will land.

Comment 24

17 years ago
Created attachment 47345 [details]
Logfile

Comment 25

17 years ago
CC'ing Darin. Could this be a http protocol bug, or should PSM fix this?

Comment 26

17 years ago
looks like the first attempt to read from the socket results in an immediate
EOF.  this tells HTTP that the server closed the connection, and the request is
redone on a new connection.  perhaps PSM needs to cache the fact that it has
already posted the CA dialog b/c there is no way to avoid the possibility of a
premature EOF.
(Reporter)

Comment 27

17 years ago
Move to future. Won't have time to fix these for 2.1
Target Milestone: 2.1 → Future

Comment 28

17 years ago
Removing Topembed Keyword
Keywords: topembed

Comment 29

17 years ago
Changing my prefered e-mail address.
Assignee: kai.engert → kaie

Comment 30

17 years ago
The behavior is still present in the 10/5 branch build.
QA Contact: ckritzer → junruh
Version: 2.0 → 2.1

Comment 31

17 years ago
*** Bug 114721 has been marked as a duplicate of this bug. ***

Comment 32

17 years ago
Queried for 'certificate cancel' before I filed a dupe. Fixing summary.
Summary: Unrecognized CA dialog presented twice upon cancel → Unrecognized certificate authority dialog presented twice upon cancel
(Assignee)

Updated

16 years ago
Blocks: 149910
This is a consequence of the problem reported in bug 149910.
When a TLS handshake attempt fails, in almost all cases, PSM treats it
as a TLS intolerant server, and forces necko to retry using SSL3 
instead of TLS by returning an EOF to the first read.  

The proper solution to this problem is NOT (IMO) to "remember" that
the user elected to not accept this certificate when PSM retries 
with SSL3.  Rather, the proper solution is to NOT retry with SSL3
when the error is one that we know cannot be fixed by switching 
from TLS to ssl3.  

I think once bug 149910 is fixed, this bug 87209 will simply go away.
There are other, similar, bugs that will go away then, too.

Updated

16 years ago
Keywords: nsbeta1
Version: 2.1 → 2.3
(Assignee)

Updated

16 years ago
Keywords: nsbeta1 → nsbeta1+
(Assignee)

Comment 34

16 years ago
I want to fix this together with the patch in bug 87902 (do not confuse numbers,
this bug has a very similar number :-)
(Assignee)

Comment 35

16 years ago
Fixed on trunk with patch for bug 87902.
Status: NEW → RESOLVED
Last Resolved: 16 years ago
Depends on: 87902
Resolution: --- → FIXED

Comment 36

16 years ago
Verified.
Status: RESOLVED → VERIFIED

Updated

14 years ago
Component: Security: UI → Security: UI
Product: PSM → Core

Updated

10 years ago
Version: psm2.3 → 1.0 Branch
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.