Hi Kaspar,
thanks again for review!
On Wed October 21 2009 08:05:29 Kaspar Brand wrote:
> I would suggest to reword the warnings in Curl_nss_connect to something
> like "TLS disabled due to previous handshake failure" and "Error in TLS
> handshake, trying SSLv3...", respectively.
No problem.
> You're right, for NSS this is currently the only viable solution to turn
> off TLS extensions in the ClientHello in NSS. Maybe NSS should add
> support for setting another option for an SSL socket, something like
> SSL_DISABLE_TLS_EXTENSIONS... What about your contacts to the NSS people
I'll check their bugzilla and perhaps fill a bug requesting this. But prepare
yourself to answer possible questions since I am not familiar with the SSL/TLS
terminology at all ;-)
> within Redhat (Elio, Bob, ...), would they listen to you and make sure
> that this happens "reasonably soon"? ;-)
They'll also listen to you. AFAICT the NSS development is not controlled
by RH. The final decision usually hangs on Nelson Bolyard who has nothing
to do with RH. But he is fairly openminded to good ideas.
>From their perspective, Firefox works, no bugs are filled by users in regard
to this aspect ... I don't think there is a good chance to implement such
extension right now.
> True, all the logic is within the *_connect routines. Are you
> considering to add similar workarounds for the OpenSSL and GnuTLS
> specific code, or are you focusing on the NSS stuff right now?
I am interested only in NSS, but will try to move as much code as possible
to the common layer to make it easier to implement the same for other SSL
libraries.
> The changes to lib/nss.c look reasonable to me, as far as they relate to
> NSS. I'm not familiar with curl's retry logic, so I defer comments about
> that to others following this thread.
Daniel, could you please comment at this ^^^?
> There's one caveat with this strategy: a URL could also get into this
> "TLS incapable" state due to a transient problem with the handshake
> (with the SSL_ERROR_HANDSHAKE_FAILURE_ALERT error e.g.). In a
> long-living process, this could mean that libcurl never retries to
> connect with TLS, even if it was supported by the server (and therefore
> preferrable over SSLv3). My previous comment actually referred to this
> situation - so all in all, the approach with patch v1 seems better to
> me, actually (i.e., do not remember the state in libcurl forever, and
> retry with TLS whenever you're connecting again).
Well, I have *no* problem with neither v1 nor v2 strategy. I think both
scenarios are more acceptable for users than getting nothing from a broken
TLS server. But there should be some consensus on the list before I post
final version of the patch. Just for summary, we have two choices:
1) cache the "broken TLS server" state per handle
+ only one unsuccessful attempt per handle's life
- once the TLS connection fail with certain error, it won't try to
connect using TLS any more per handle's life
2) do not cache the "broken TLS server" state per handle
+ we have chance to negotiate TLS per each connection
- one unsuccessful attempt per each connection (before the successful one)
if the TLS server stays broken
Kamil
-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette: http://curl.haxx.se/mail/etiquette.html
