423499 - Can't access webmin on adjacent host

Status: RESOLVED WORKSFORME

(Core :: Security: PSM, defect)

Description

[u123541]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9b5pre) Gecko/2008031504 Minefield/3.0b5pre
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9b5pre) Gecko/2008031504 Minefield/3.0b5pre

Yes, that's simply https://www:10000 in above URL... it gives:
  The certificate is not trusted because it is self signed.
  (Error code: sec_error_untrusted_issuer)
[Add exception...] gives:
[Confirm Security Exception] which is inactive.

Reproducible: Always

Steps to Reproduce:
1. connect to adjacent www machine
2. can't confirm security exception
3.
Actual Results:  
no access

Expected Results:  
access

There are other reports on this issue; but I decided to keep this simple and avoid the political/usability discussions.

I don't care if there are more "Confirm" steps; but no way forward forces me to use another browser...  :(

Comment 1

[u123541]

More info...  when getting into this situation on other hosts, I can get that site's certificate and proceed; but when connecting to webmin, there is no option to display the certificate making access impossible.

Comment 2

[Robert Accettura [:raccettura]]

Confirming there is an NSS regression somewhere.  

I've got webmin on a NAT'd box runing on port 10000 using SSL (via SSLeay in perl.  OpenSSL/0.9.7l on the box).  In Safari 3/Firefox 2 I'm told about the self signed cert.

In 2008032204 I get:
Firefox can't establish a connection to the server at 192.168.xxx.xxx:10000.

This clearly isn't right.  It should prompt me about the cert, and require me to add an exception.

Comment 3

[Robert Accettura [:raccettura]]

This is really starting to suck.  My suspicion is that NSS doesn't like port 10000 for some reason, but I've yet to prove this.

Comment 4

[:Gavin Sharp [email: [e-mail]]]

There are two conflicting bug reports here - comment 0 says that the "bad cert" error page appears, but that when you try to add the security exception, the "confirm security exception" button is disabled (but doesn't mention clicking "Get Certificate", which is required). Comment 2 says that a "can't connect" error page is shown instead of a  "bad cert" error page, which sounds like a different bug. Robert, can you file a new bug for your issue, so that we can keep track of these separately?

Pierre: did you click "Get Certificate" before trying to "Confirm Security Exception"? If the button still doesn't work after that, you may be seeing bug 406954, which was fixed after beta 5.

Comment 5

[Gen Kanai [:gen]]

Adding a few of the NSS maintainers.

Comment 6

[u123541]

It seems to be working well now...  thanks.

Comment 7

[Jean-Marc Desperrier]

Robert, would you be able to dump what happens on the network using WireShark ?
( http://www.wireshark.org/ )

Til now  it's not clear if it's a problem with the port number or with the ssl handshake. A WireShark trace would clarify things.

Comment 8

[Nelson Bolyard (seldom reads bugmail)]

- Comment 0 and comment 2 are reporting two separate issues.
Robert, Failure to connect is a TCP issue, not an SSL issue.

- I haven't seen any evidence of an NSS problem yet.
An inactive "Add exception" button is not evidence of an NSS problem.
NSS doesn't do UI.

If you haven't yet gotten past the add-exception dialog, then this is 
probably just a certificate issue, and not an SSL issue.  
I wouldn't bother with any SSL traces until the cert itself has been 
vindicated.  You could attach a copy of the cert to this bug.

If and when it becomes appropriate to look at SSL traces, ssltap or ssldump 
output is *always* preferable to wireshark output.  I'm inclined to say 
that ssltap/ssldump output is required, rather than wireshark output, 
if it comes to that.

Comment 9

[Jean-Marc Desperrier]

Well, I suggested WireShark because *I*'d be able to help with a WireShark trace.
And also because it would show what happens even if the problem had nothing to do with SSL, which seemed likely. I would easily prove if the problem was coming from a tcp drop instead.

On a side note and AFAIC I was *very* *happy* recently to discover that WireShark enabled me to definitively dump ssldump in favor of a program that's *maintained*, *easy to use and install on all platforms*, compatible with recent tcpdump (the ones that recognize gbit-able ethernet cards), able to display *all* normalized aspects of SSL, this includes all security suits, all tls extensions (I used it recently for checking negotiation of the Maximum Fragment Length extension) and not just decode the inside encrypted traffic but interpret it. 
You could have your quirks for favoring ssltap, but except pure ignorance I can't find anything that justifies still using ssldump at this time.

Comment 10

[Nelson Bolyard (seldom reads bugmail)]

Jean-Marc,  If you're willing to help with wireshark traces, then you are
of course free and welcome to do so.  I would be VERY (pleasantly) surprised
if wireshark can correctly interpret all the latest cipher suites and TLS
extensions supported in NSS 3.12, and output them in as readable and usable
fashion as ssltap, but if it does, then I don't object to others using it to
produce that usable output.  But I have no wish to do so.

I know that ssltap produces very usable output, and it is my preferred format.
It is maintained as part of NSS.

I haven't used ssldump for some time (~ 1 year), but the last time I used it
its output was satisfactory.  Plus it had one advantage over ssltap, which is
that it was able to decode several simultaneous SSL connections, while ssltap
is only able to decode one connection at a time.  

Comment 11

[Robert Accettura [:raccettura]]

Considering I've yet to get ssldump or ssltap going, and apparently I'm the only one... I'm going to admit defeat and let this one live for a while.  Perhaps at some point in the future I'll try and dig deeper.  As long as it's isolated, it's quite frankly not worth the effort. Something must be odd on that box, and tripping things up.

Comment 12

[Jean-Marc Desperrier]

(In reply to comment #10)
I overreacted on that one. Just let's forget about it, and just say that wireshard recently has became an excellent product for ssl analysis (the only quirk is the edit/preference/Protocols/ssl/rsa key list/"ip adress,port,inner protocol,private key pem file path" format to decode ssl traffic that's really hidden and inconvenient) and you should thing about having a better look at it some day.

(In reply to comment #11)
> Considering I've yet to get ssldump or ssltap going

I may seem insisting, but it should take you only minutes to install and get wireshark working, type tcp.port == 1000 for the filter, and you should see what happens. And it could happen it's convenient another day to have it installed to investigate network, http headers or xml soap problems.

Comment 13

[Robert Accettura [:raccettura]]

Problem is actually dll hell from what looks like GTK (likely conflicting with either Pidgin or XChat's install).

Comment 14

[Jean-Marc Desperrier]

Ok, so we can close the bug ?

Comment 15

[Robert Accettura [:raccettura]]

If someone disagrees, reopen.

Thanks to all.