[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: lib/46878: connection to some https site using openssl causesfreeze
The following reply was made to PR lib/46878; it has been noted by GNATS.
From: Izumi Tsutsui <tsutsui%ceres.dti.ne.jp@localhost>
Subject: Re: lib/46878: connection to some https site using openssl causesfreeze
Date: Wed, 3 Oct 2012 00:18:23 +0900
> In the end, NetBSD desktop users cannot use these sites with OpenSSL
> based https, and NetBSD desktop becomes less useful for usual users.
Unfortunately, most typical NetBSD users and developers have
less interests in marketing and desktop environments ;-p
You should rather mention technical merit on it.
If you'd like to integrate a patch to solve your problem,
you should mention at least:
- what's the actual problem
=> SSL access hangs on *some* specific sites?
- what's the route cause
=> you didn't track it, right?
- how does the proposed patch fix (or work around) the problem
=> I guess your patch is a "kludge", not a real fix
(even if ubuntu has accepted it)
- if the patch is not a "real fix", what's the possible bad side effects
=> appearently network embeded users rather want proper TLS 1.2 support
rather than nicovideo support (IIRC gnash doesn't support it either)
On the other hand, openssl changelogs say:
Changes between 1.0.1 and 1.0.1a [19 Apr 2012]
*) Workarounds for some broken servers that "hang" if a client hello
record length exceeds 255 bytes:
1. Do not use record version number > TLS 1.0 in initial client
hello: some (but not all) hanging servers will now work.
2. If we set OPENSSL_MAX_TLS1_2_CIPHER_LENGTH this will truncate
the number of ciphers sent in the client hello. This should be
set to an even number, such as 50, for example by passing:
-DOPENSSL_MAX_TLS1_2_CIPHER_LENGTH=50 to config or Configure.
Most broken servers should now work.
3. If all else fails setting OPENSSL_NO_TLS1_2_CLIENT will disable
TLS 1.2 client support entirely.
- the problem was ack'ed by openssl guys
- apearently the problem is at server side
- "-DOPENSSL_MAX_TLS1_2_CIPHER_LENGTH=XX" could be another compromise
And 1.0.1d (newer than our 1.0.1c) includes the following entry:
Changes between 1.0.1c and 1.0.1d [xx XXX xxxx]
*) Don't use TLS 1.0 record version number in initial client hello
Could you try this renegotiation change?
(I have not checked actuall changes though)
Main Index |
Thread Index |