On 06/23/2015 01:17 AM, Bernd Eckenfels wrote:
Hello,
this is a general comment, not necesarily applicable for the OCSP
stapling options directly:
Am Tue, 23 Jun 2015 15:39:30 +0800
schrieb Xuelei Fan<xuelei....@oracle.com>:
Caches, for example session/trust manager/key manager, are used a lot
in SSL/TLS handshaking. Dynamic system property may make the
behavior a little bit complicated. In general, if not necessary, I
would prefer to use static system property as what we did before for
similar properties. Developers only need to understand one mode, as
would simplify the learning curve, I think.
But its a huge problem when you have to interface with multiple
partners. This especially is for turning features on and off. One
server does not allow to use SNI, the other requires it. One would use
a weak DHE key when DHE is enabled, the other would not use forward
secrecy without. Some implementation fails with OCSP extensions the
other not (etc).
So a general interface for setting those parameters on the
context/sesssion/factory instead of (only) system properties would be
great.
Gruss
Bernd
Hi Bernd,
Having an API to control stapling was part of the original design. In
the months that followed, other initiatives like a general-purpose TLS
extensions API made us decide to hold off on trying to make something
specific to this one extension. We didn't want to come out of the gate
with an API that was very shortly superseded by another more general
purpose one.
That is also why I tried to give at least a little dynamic control over
the properties we do have. For instance, if you want to have different
server-side stapling settings that affect cache lifetimes or sizing, or
not passing OCSP extensions, those properties can be set before you
create an SSLContext. Then they can be altered before creating a second
SSLContext to get different behavior.
As Xuelei said, in the future there will be a way to customize stapling
behavior both client and server side.
--Jamil
