Session resumption

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

Session resumption

John Jiang
I'm Using bctls-jdk15on-1.58.jar
Does BC TLS server/client support session resumption via session id?
I just find some TlsServer/TlsClient APIs on session ticket.

Thanks!
Reply | Threaded
Open this post in threaded view
|

Re: Session resumption

Peter Dettman-3
Hi John,

Session resumption is supported on the client side, not yet on the
server side, although it is likely to be added soon since there is
increasing interest.

If you are using the BCJSSE provider, client-side session resumption
should be automatic for connections to the same host/port. In the basic
TLS API, it is not automatic, it requires overriding a couple of methods
in the TlsClient subclass (collect session from the context in
notifyHandshakeComplete, return it during a future handshake from
getSessionToResume).

BTW, session tickets are not fully implemented, although some
preliminary steps are done.

Regards,
Pete Dettman

On 19/3/18 6:05 pm, John Jiang wrote:
> I'm Using bctls-jdk15on-1.58.jar
> Does BC TLS server/client support session resumption via session id?
> I just find some TlsServer/TlsClient APIs on session ticket.
>
> Thanks!


Reply | Threaded
Open this post in threaded view
|

Re: Session resumption

John Jiang
Hi Peter,
Thanks for your clarification!

In addition, with my test, if using cipher suites TLS_DHE_*, like TLS_DHE_RSA_WITH_AES_128_CBC_SHA, BC thrown the below exception,
org.bouncycastle.tls.TlsFatalAlert: insufficient_security(71)
    at org.bouncycastle.tls.TlsDHUtils.receiveDHConfig(Unknown Source)
    at org.bouncycastle.tls.TlsDHEKeyExchange.processServerKeyExchange(Unknown Source)
    at org.bouncycastle.tls.TlsClientProtocol.handleHandshakeMessage(Unknown Source)
    at org.bouncycastle.tls.TlsProtocol.processHandshakeQueue(Unknown Source)
    at org.bouncycastle.tls.TlsProtocol.processRecord(Unknown Source)
    at org.bouncycastle.tls.RecordStream.readRecord(Unknown Source)
    at org.bouncycastle.tls.TlsProtocol.safeReadRecord(Unknown Source)
    at org.bouncycastle.tls.TlsProtocol.blockForHandshake(Unknown Source)
    at org.bouncycastle.tls.TlsClientProtocol.connect(Unknown Source)

Is it a known issue? Or, I still missed something.

Thanks!

2018-03-20 14:00 GMT+08:00 Peter Dettman <[hidden email]>:
Hi John,

Session resumption is supported on the client side, not yet on the
server side, although it is likely to be added soon since there is
increasing interest.

If you are using the BCJSSE provider, client-side session resumption
should be automatic for connections to the same host/port. In the basic
TLS API, it is not automatic, it requires overriding a couple of methods
in the TlsClient subclass (collect session from the context in
notifyHandshakeComplete, return it during a future handshake from
getSessionToResume).

BTW, session tickets are not fully implemented, although some
preliminary steps are done.

Regards,
Pete Dettman

On 19/3/18 6:05 pm, John Jiang wrote:
> I'm Using bctls-jdk15on-1.58.jar
> Does BC TLS server/client support session resumption via session id?
> I just find some TlsServer/TlsClient APIs on session ticket.
>
> Thanks!



Reply | Threaded
Open this post in threaded view
|

Re: Session resumption

Peter Dettman-3
Hi John,
In TLS the server chooses the DH group that will be used for the key
exchange. It can be any arbitrary group, although some were
standardized. Actually in reality it can be any pair of numbers and this
presents the issue that it's difficult/expensive for the client to check
that (previously unseen) ServerDHParams are a secure choice.

RFC 7919 improved the situation somewhat by specifying a TLS extension
for negotiating the choice of DH group from a fixed list, in the same
spirit that an EC curve is negotiated. It requires both ends of the
connection to implement the extension though. Note that well-known DH
groups used by many connections also have their own issues [1].

In any event the client has to decide whether it is satisfied with the
DH group, and in BC you control this policy through the implementation
of TlsDHConfigVerifier that is passed in the DefaultTlsClient constructor.

DefaultTlsDHConfigVerifier is the default implementation; it only
accepts known groups from RFC 3526 and RFC 7919, using at least a
2048-bit prime.

Rough order of recommmendation:
- If you have ECDHE_* cipher suites enabled and you don't absolutely
need DHE_* cipher suites, then just disable DHE_*.
- ELSE If you control the server-side for your application, then enable
RFC 7919 support there, or configure the server(s) with one of those DHE
groups explicitly, or generate a strong DH group to use, and add it to
the list that your client will accept.
- ELSE If your client will connect to arbitrary servers, you can as a
last resort customize the TlsDHConfigVerifier to accept any
server-specified "group" (of a minimum size), which is essentially back
to square one for DHE.

Regards,
Pete Dettman

[1] https://weakdh.org

On 23/3/18 9:39 am, John Jiang wrote:

> Hi Peter,
> Thanks for your clarification!
>
> In addition, with my test, if using cipher suites TLS_DHE_*, like
> TLS_DHE_RSA_WITH_AES_128_CBC_SHA, BC thrown the below exception,
> org.bouncycastle.tls.TlsFatalAlert: insufficient_security(71)
>     at org.bouncycastle.tls.TlsDHUtils.receiveDHConfig(Unknown Source)
>     at
> org.bouncycastle.tls.TlsDHEKeyExchange.processServerKeyExchange(Unknown
> Source)
>     at
> org.bouncycastle.tls.TlsClientProtocol.handleHandshakeMessage(Unknown
> Source)
>     at org.bouncycastle.tls.TlsProtocol.processHandshakeQueue(Unknown
> Source)
>     at org.bouncycastle.tls.TlsProtocol.processRecord(Unknown Source)
>     at org.bouncycastle.tls.RecordStream.readRecord(Unknown Source)
>     at org.bouncycastle.tls.TlsProtocol.safeReadRecord(Unknown Source)
>     at org.bouncycastle.tls.TlsProtocol.blockForHandshake(Unknown Source)
>     at org.bouncycastle.tls.TlsClientProtocol.connect(Unknown Source)
>
> Is it a known issue? Or, I still missed something.
>
> Thanks!