Last Comment Bug 924381 - Allow applications to handle (re)handshakes specially
: Allow applications to handle (re)handshakes specially
Status: NEW
:
Product: NSS
Classification: Components
Component: Libraries (show other bugs)
: 3.15.1
: All All
: -- normal (vote)
: ---
Assigned To: nobody
:
Mentors:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2013-10-08 06:40 PDT by Miloslav Trmač
Modified: 2013-11-26 14:28 PST (History)
3 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---


Attachments

Description Miloslav Trmač 2013-10-08 06:40:47 PDT
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*).
Comment 1 Kai Engert (:kaie) 2013-11-26 13:43:32 PST
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 Kai Engert (:kaie) 2013-11-26 13:57:02 PST
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 Dan Winship 2013-11-26 14:28:24 PST
(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().

Note You need to log in before you can comment on or make changes to this bug.