Hi,
we've got this SSL web server setup, [ actually several servers on a round robin DNS entry, using the same key and cert. ]
We have a sort of intermittent, connection failure. The setup has worked with IE6 and ie7 on windows, as well as safari, camino, opera, and firefox on osx. However now we have safari on one guys machine and camino on my machine who's connections fail, it's not a general problem, the bad safari has been restarted, and all the servers have been restarted but the problems persist. Safari on another machine does not exhibit the problem. The problem was also reported by our partners who I believe were using windows. however they only reported it as, "the servers were working, then for a while they gave no response, but it's working now". All of that was enough to convince us that while the problem is hard to reproduce, it's definitely real.
So.. I resort to tcpdump and wireshark. I can see that the on the two "bad" instances of browsers available to me, one tries to resume a previous ssl session. (camino) the other (safari) seems to start normal. The handshake I don't fully understand seems to happen, and then the server sends back an "Encrypted Alert" and the connection shuts down.
I would greatly appreciate any help in debugging this. I'm not sure what to try next, especially since I can't reliably recreate the problem.
I'm attaching the tcpdump files, a bad connection from camino, a bad connection from safari, and a good connection from firefox, in case you're inclined to look at em.
a little other background, the server is called yaws, which is written in erlang, which uses a seperate SSL library that bridges erlang to openssl code. so there's risk that these have their own problems therefore it would be nice to know if somehow the protocol is being executed improperly or not.
I don't know what the encrypted alert means, I tried giving wireshark the server key so that it could maybe decrypt this alert, if that's what needs to be done, but the ssl decryption in wireshark seemed to only work for the "good firefox" connection. either that or there just wasn't anything to decrypt in the bad connections.
badcamino.tcpdump
Description: Binary data
goodfirefox.tcpdump
Description: Binary data
badsafari.tcpdump
Description: Binary data
--fess
