On Tue, Jan 09, 2001 at 04:47:58PM -0500, Colin Devine wrote:
> Okay, I tried the open_ssl-0.95a and also a snake-oil certificate with no
> luck. Hell maybe it is a dns problem...it kinda of looks like it, but I
> think it just the server taking forever to push out the content...the max
> speed I was getting was about 500b/s download, with most being
> around 30/b/s and dropping...and the connections would take forever (30s -
> 1 min). I don't know what the hell it is. So onto the pseudo random
> thing. Again, thanks for all the help people. I really want this thing
> to work, and it appears that you do too.
Please check out some additional things:
- If it is a DNS problem, you would see it when establishing the session,
as this is when lookup takes place. It would not influence the transfer
rate during the session.
- If it is a random number problem, it would be similar, as entropy is
queried on startup and on opening of the connection.
- I remember having seen problems with Netscape and normal (no TLS/SSL)
connections with some sites. The data came in fast and was more or less
complete (totally complete from my impression), but the transfer was not
flagged as finished and hence Netscape waited (for the last byte to come
in?). Of course, the average transfer rate displayed was reduced during
this waiting process. I don't remember which sites these were and actually
there was our universities proxy in between, so please don't ask for
details.
- It might be intersting to dump the SSL connection and do some investigations.
There is the ssldump utility (http://www.rtfm.com/ssldump) with which
you can dump SSL sessions or analyze dumped sessions. I personally am
lazy and tend to capture sessions with ethereal, then analyze the saved
dump with ssldump.
If you use a non-(E)DH cipher like RC4-MD5 (the cipher typically used by
Netscape with OpenSSL servers), you can even decrypt the full session by
supplying the private key.
The dump will show you the exact package contents and timing, so that you
can see at which point the delay(s) are introduced.
If you cannot interpret the dump yourself, you can send the output
(I would recommend the decrypted one).
Best regards,
Lutz
--
Lutz Jaenicke [EMAIL PROTECTED]
BTU Cottbus http://www.aet.TU-Cottbus.DE/personen/jaenicke/
Lehrstuhl Allgemeine Elektrotechnik Tel. +49 355 69-4129
Universitaetsplatz 3-4, D-03044 Cottbus Fax. +49 355 69-4153
______________________________________________________________________
Apache Interface to OpenSSL (mod_ssl) www.modssl.org
User Support Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
