Quantcast

TlsPSKProtocolTest fails with TLS_PSK_WITH_NULL_SHA256

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

TlsPSKProtocolTest fails with TLS_PSK_WITH_NULL_SHA256

Alexander Farber
Good afternoon,

I have copied the files TlsPSKProtocolTest.java, MockPSKTlsClient.java, MockPSKTlsServer.java into a small Maven-based project:

https://github.com/afarber/jetty-newbie/tree/master/TlsPskServer/src/main/java/de/afarber/tlspskserver

and it runs well. However, changing the both getCiphers methods to

    @Override
    protected int[] getCipherSuites()
    {
        return new int[] {
            CipherSuite.TLS_PSK_WITH_NULL_SHA256
        };
    }

causes the runtime error:

TLS-PSK server negotiated TLS 1.2
TLS-PSK server raised alert: fatal(2), handshake_failure(40)
> Failed to read record
org.bouncycastle.crypto.tls.TlsFatalAlert: handshake_failure(40)
    at org.bouncycastle.crypto.tls.AbstractTlsServer.getSelectedCipherSuite(Unknown Source)
    at org.bouncycastle.crypto.tls.TlsServerProtocol.sendServerHelloMessage(Unknown Source)
    at org.bouncycastle.crypto.tls.TlsServerProtocol.handleHandshakeMessage(Unknown Source)
    at org.bouncycastle.crypto.tls.TlsProtocol.processHandshake(Unknown Source)
    at org.bouncycastle.crypto.tls.TlsProtocol.processRecord(Unknown Source)
    at org.bouncycastle.crypto.tls.RecordStream.readRecord(Unknown Source)
    at org.bouncycastle.crypto.tls.TlsProtocol.safeReadRecord(Unknown Source)
    at org.bouncycastle.crypto.tls.TlsProtocol.blockForHandshake(Unknown Source)
    at org.bouncycastle.crypto.tls.TlsServerProtocol.accept(Unknown Source)
    at de.afarber.tlspskserver.TlsPSKProtocolTest$ServerThread.run(TlsPSKProtocolTest.java:90)
java.io.IOException: Internal TLS error, this could be an attack
TLS-PSK client received alert: fatal(2), handshake_failure(40)
Exception in thread "main" java.io.IOException: Internal TLS error, this could be an attack
    at org.bouncycastle.crypto.tls.TlsProtocol.processAlert(Unknown Source)
    at org.bouncycastle.crypto.tls.TlsProtocol.processRecord(Unknown Source)
    at org.bouncycastle.crypto.tls.RecordStream.readRecord(Unknown Source)
    at org.bouncycastle.crypto.tls.TlsProtocol.safeReadRecord(Unknown Source)
    at org.bouncycastle.crypto.tls.TlsProtocol.blockForHandshake(Unknown Source)
    at org.bouncycastle.crypto.tls.TlsClientProtocol.connect(Unknown Source)
    at de.afarber.tlspskserver.TlsPSKProtocolTest.testClientServer(TlsPSKProtocolTest.java:54)
    at de.afarber.tlspskserver.Main.main(Main.java:17)

What could be the cause for that, is TLS_PSK_WITH_NULL_SHA256 not supported?

My long term target is to create a small "reverse proxy" in front of embedded Jetty 9, which would support TLS-PSK connections.

Greetings from Germany
Alex

P.S. I have donated 5 dollar to Bouncy Castle Inc. <:-)
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: TlsPSKProtocolTest fails with TLS_PSK_WITH_NULL_SHA256

Peter Dettman-3
Hi Alex,
The ciphersuite should be supported, but there was a bad interaction
with the encrypt-then-MAC extension negotiation. It's fixed in our git
now (github mirror can take a while to update). I mention workarounds
you can use until the next release at
https://github.com/bcgit/bc-java/issues/166.

Thanks for the bug report, and for the donation!

Regards,
Pete Dettman

On 11/11/2016 7:09 PM, Alexander Farber wrote:

> Good afternoon,
>
> I have copied the files TlsPSKProtocolTest.java, MockPSKTlsClient.java,
> MockPSKTlsServer.java into a small Maven-based project:
>
> https://github.com/afarber/jetty-newbie/tree/master/TlsPskServer/src/main/java/de/afarber/tlspskserver
>
> and it runs well. However, changing the both getCiphers methods to
>
>     @Override
>     protected int[] getCipherSuites()
>     {
>         return new int[] {
>             CipherSuite.TLS_PSK_WITH_NULL_SHA256
>         };
>     }
>
> causes the runtime error:
>
> TLS-PSK server negotiated TLS 1.2
> TLS-PSK server raised alert: fatal(2), handshake_failure(40)
>> Failed to read record
> org.bouncycastle.crypto.tls.TlsFatalAlert: handshake_failure(40)
>     at
> org.bouncycastle.crypto.tls.AbstractTlsServer.getSelectedCipherSuite(Unknown
> Source)
>     at
> org.bouncycastle.crypto.tls.TlsServerProtocol.sendServerHelloMessage(Unknown
> Source)
>     at
> org.bouncycastle.crypto.tls.TlsServerProtocol.handleHandshakeMessage(Unknown
> Source)
>     at org.bouncycastle.crypto.tls.TlsProtocol.processHandshake(Unknown
> Source)
>     at org.bouncycastle.crypto.tls.TlsProtocol.processRecord(Unknown Source)
>     at org.bouncycastle.crypto.tls.RecordStream.readRecord(Unknown Source)
>     at org.bouncycastle.crypto.tls.TlsProtocol.safeReadRecord(Unknown
> Source)
>     at org.bouncycastle.crypto.tls.TlsProtocol.blockForHandshake(Unknown
> Source)
>     at org.bouncycastle.crypto.tls.TlsServerProtocol.accept(Unknown Source)
>     at
> de.afarber.tlspskserver.TlsPSKProtocolTest$ServerThread.run(TlsPSKProtocolTest.java:90)
> java.io.IOException: Internal TLS error, this could be an attack
> TLS-PSK client received alert: fatal(2), handshake_failure(40)
> Exception in thread "main" java.io.IOException: Internal TLS error, this
> could be an attack
>     at org.bouncycastle.crypto.tls.TlsProtocol.processAlert(Unknown Source)
>     at org.bouncycastle.crypto.tls.TlsProtocol.processRecord(Unknown Source)
>     at org.bouncycastle.crypto.tls.RecordStream.readRecord(Unknown Source)
>     at org.bouncycastle.crypto.tls.TlsProtocol.safeReadRecord(Unknown
> Source)
>     at org.bouncycastle.crypto.tls.TlsProtocol.blockForHandshake(Unknown
> Source)
>     at org.bouncycastle.crypto.tls.TlsClientProtocol.connect(Unknown Source)
>     at
> de.afarber.tlspskserver.TlsPSKProtocolTest.testClientServer(TlsPSKProtocolTest.java:54)
>     at de.afarber.tlspskserver.Main.main(Main.java:17)
>
> What could be the cause for that, is TLS_PSK_WITH_NULL_SHA256 not supported?
>
> My long term target is to create a small "reverse proxy" in front of
> embedded Jetty 9, which would support TLS-PSK connections.
>
> Greetings from Germany
> Alex
>
> P.S. I have donated 5 dollar to Bouncy Castle Inc. <:-)


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: TlsPSKProtocolTest fails with TLS_PSK_WITH_NULL_SHA256

Alexander Farber
Hello Peter, thank you -

On Fri, Nov 11, 2016 at 4:41 PM, Peter Dettman <[hidden email]> wrote:
The ciphersuite should be supported, but there was a bad interaction
with the encrypt-then-MAC extension negotiation. It's fixed in our git
now (github mirror can take a while to update). I mention workarounds
you can use until the next release at
https://github.com/bcgit/bc-java/issues/166.
 
after I have commented the line in my copy of MockPSKTlsClient.java:

@Override
    public Hashtable getClientExtensions() throws IOException
    {
        Hashtable clientExtensions = TlsExtensionsUtils.ensureExtensionsInitialised(super.getClientExtensions());
        // TlsExtensionsUtils.addEncryptThenMACExtension(clientExtensions);
        return clientExtensions;
    }

the problem with TLS_PSK_WITH_NULL_SHA256 was gone, as you suggested.

However I would like to support 2 ciphers:

TLS_PSK_WITH_NULL_SHA256 and 
TLS_PSK_WITH_AES_128_CBC_SHA256

Is it maybe possible to see (either at the client or at the server side), which cipher is being used - and only apply the workaround for the former one?

Greetings from Germany
Alex 
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: TlsPSKProtocolTest fails with TLS_PSK_WITH_NULL_SHA256

Peter Dettman-3
Hi Alex,

Try overriding AbstractTlsServer.allowEncryptThenMAC():

    protected boolean allowEncryptThenMAC()
    {
        return TlsUtils.getEncryptionAlgorithm(this.selectedCipherSuite)
!= EncryptionAlgorithm.NULL;
    }


That should fix the issue for all ciphersuites and allow
encrypt-then-MAC to still work (you won't need a modified client anymore).

Hopefully a new release with the fix is not far off in any case.

Regards,
Pete Dettman


On 11/11/2016 11:56 PM, Alexander Farber wrote:

> the problem with TLS_PSK_WITH_NULL_SHA256 was gone, as you suggested.
>
> However I would like to support 2 ciphers:
>
> TLS_PSK_WITH_NULL_SHA256 and
> TLS_PSK_WITH_AES_128_CBC_SHA256
>
> Is it maybe possible to see (either at the client or at the server
> side), which cipher is being used - and only apply the workaround for
> the former one?
>
> Greetings from Germany
> Alex


Loading...