Note: There are a few cases of duplicates in user autocompletion which are being worked on.

Allow applications to handle (re)handshakes specially

NEW
Unassigned

Status

NSS
Libraries
4 years ago
4 years ago

People

(Reporter: Miloslav Trmač, Unassigned)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

4 years ago
User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Firefox/24.0 (Beta/Release)
Build ID: 20130917102605

Steps to reproduce:

Some application environments (e.g. the glib/gtk+ ecosystem) are primarily designed around a poll() event loop, with each event handled with minimal blocking/latency, rather than concurrently running threads.

In such an environment, the automatic/transparent renegotiation handling inside a PR_Read/PR_Write call is problematic, because the renegotiation may require asymmetric crypto operations (CPU-intensive, on slow CPUs resulting in noticeable UI lag), or smart card operations, or even user interaction.

Specifically, glib-networking performs most read/write operations on the main thread, integrating the sockets into the main poll() event loop to avoid blocking, but if a renegotiation is necessary, it creates a temporary thread to perform the blocking renegotiation-related operations.

Right now, glib-networking needs to intercept all incoming TLS records (using a new PRIOMethods class) before they are handed to NSS, to detect when renegotiation will take place.  This is fairly complex and hackish.

It would be much cleaner if NSS made it possible to configure a socket to disable automatic renegotiations, where PR_Read/PR_Write would instead of starting a renegotiation return a special error code; the application would then know that a blocking operation will be needed, and could handle it as necessary (probably eventually initiating the actual renegotiation using SSL_ForceHandshake*).

Updated

4 years ago
Status: UNCONFIRMED → NEW
Ever confirmed: true

Comment 1

4 years ago
In the explanation, you seem to talk about the renegoation scenario, only.

But in the summary you wrote "(re)handshake".

Are you requesting that the initial handshake should return with a special error, too, if the socket has been configured in the way you propose?

Comment 2

4 years ago
I'd like to request a more detailed description of the enhancement request.

(a)
I assume you'd like to use this feature in clients, only, correct?

(b)
At which point during the handshake should the handshake be paused with an error return?
http://www.cisco.com/image/gif/paws/116181/116181-technote-product-01.png

(c)
Pause at one point, only, or at multiple points?

Comment 3

4 years ago
(In reply to Kai Engert (:kaie) from comment #1)
> Are you requesting that the initial handshake should return with a special
> error, too, if the socket has been configured in the way you propose?

In the initial handshake case, you already know that a handshake is about to happen. So we don't *need* to have NSS tell us about it, but it's fine if it does.

(In reply to Kai Engert (:kaie) from comment #2)
> I assume you'd like to use this feature in clients, only, correct?

No, clients and servers.

> (b)
> At which point during the handshake should the handshake be paused with an
> error return?
> http://www.cisco.com/image/gif/paws/116181/116181-technote-product-01.png
>
> (c)
> Pause at one point, only, or at multiple points?

gnutls does it whenever a client receives a HelloRequest, or a server receives a non-initial ClientHello.

But it seems like you could also just return the error whenever you decide you need to send a handshake packet, and you're not inside SSL_ForceHandshake().
You need to log in before you can comment on or make changes to this bug.