Michel wrote:
Hello,
I realize this is a Mozilla developer newsgroup, but I hope my question
will go direct to someone who knows how to diagnose the problem
correctly (I don't have that knowledge):
You came to the right place. The participants in this group don't
get too hung up on the developer-vs-user distinction that is common
in some other groups, but we do insist that the messages relate to
mozila's crypto software.
An hour or two I tried ordering a book at amazon.ca (the Canadian branch
of the Amazon monster) using the release version of Mozilla 1.6
(Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6) Gecko/20040113)
on Windows 2000 (SP4). On the MS IE 6.0 browser, the encrypted
connection was "TLS 1.0, RC4 with 128 bit encryption (High); RSA with
1024 bit exchange"; the Mozilla page information merely gave "High-grade
Encryption (RC4 128 bit). However, setting up the connection appeared to
be a real problem for Mozilla: at various points--seemingly randomly
chosen pages--in the succession of HTTPS pages leading to the final
checkout confirmation page, the browser would throw up a dialog
indicating that there was no common encryption that could be agreed
upon, and no further progress was responsible.
That message means that your browser and the server with which you
were trying to communicate were configured to use two disjoint sets
of ciphers, and/or two disjoint sets of SSL versions. For example,
perhaps your browser was setup to only support SSL v3, and you were
talking to a server that only talks SSL v2. You would get that message.
Or perhaps you've configured your browser to not use any of the so-called
40-bit ciphers, and you contacted a server that only speaks 40-bit
ciphers. You'd get that message.
Why would that appear to happen only on an occasional page?
The explanation that I think is most probable is that amazon.ca
probably runs a "server farm"; that is, a large collection of server
boxes that are all configured to appear to your browser to be the same
server. Each time you visit a new page, you may very well be visiting
a different server in that farm. If one of the servers in that farm
is slightly misconfigured, so that it supports a different set of
ciphers, or different SSL versions, than the other servers in the farm,
and if you've disable some of the SSL ciphers or some of the SSL versions
in your browser, then you'd see the behavior you reported.
To test this hypothesis, I suggest you examine your own mozilla browser
configuration to see what SSL versions and what ciphersuites may have
been disabled. In a browser window, go to
Edit->Preferences->Privacy+Security->SSL. Look at the checkboxes
that say "Enable SSL version 2", "Enable SSL version 3", and
"Enable TLS" (TLS is SSL version 3.1, BTW). For maximum
interoperability with other servers, you would enable all of those.
(I believe they are all enabled by default in a new installation of
mozilla). Then click on the "Edit Ciphers" button. You will see a
dialog with several tabs, each of which lists a bunch of ciphers.
For maximum interoperability, you would enable all ciphers in all tabs,
EXCEPT for the two that say "No Encryption", which (IIRC) are on the
last tab. Again, these are all enabled (except the No Encryption ones)
by default in a new installation, IINM.
Now, if you find that you have disabled some versions of SSL/TLS, or
have disabled some SSL ciphers, then I think that tends to confirm
my hypothesis about the odd server in the server farm. In that case,
I'd suggest you write to amazon.ca and tell them what you found, and
the evidence that suggests it's a bad server in the farm.
If you do NOT find any disabled SSL/TLS versions, and you do not find
any disabled ciphers (except the "No Encryption" ciphers), then something
else is afoot, and I'd like to know more.
So I restarted the whole
process (flushed the browser cache, etc.), and tried it again. Finally
it worked. (The web server was Stronghold/2.4.2 Apache/1.3.6
C2NetEU/2412 (Unix) mod_fastcgi/2.2.12 according to the Mozilla headers
info page.)
That info describes the server from which you received that particular
page. Ideally all the servers in the farm would have identical
configurations.
Is this simply a case of Mozilla being more stringent in its HTTPS
implementation than MS IE 6.0, or simply some random communication link
problem, or something else entirely? (I'm so used to Mozilla performing
reliably with most websites I've pretty much given up using the MS
browser for anything.)
MS IE gives you the choices to disable SSL2, or SSL3, or TLS (IIRC)
but it does not give you the choice of disabling individual cipher
suites, like mozilla does, IIRC. So, if you disable certain cipher
suites in mozilla that are enabled in MS IE, that could explain the
difference in behavior.
--
Nelson B
_______________________________________________
mozilla-crypto mailing list
[EMAIL PROTECTED]
http://mail.mozilla.org/listinfo/mozilla-crypto
