Non-blocking TlsProtocol accepts non-TLS data about bc-java HOT 7 CLOSED

I don't believe TlsUtils,readUint16 can return a negative value, the problem must be elsewhere. There are quite a few checks on the record sanity in RecordStream.readRecord, let me know if you think some check is missing there. I have to guess perhaps you are using offerInput by passing a fixed buffer to each call (see javadoc for why that would be a problem).

We're keen to fix this if there's an error, but I think we'll need a small test case that shows the problem.

from bc-java.

Hello @peterdettman , thank you for your quick reply. At my machine this unit test always fails. It seems to fit your hint with the fixed buffer, but I really see no other way for using this method.

import java.util.Random;

import org.apache.logging.log4j.LogManager;
import org.apache.logging.log4j.Logger;
import org.bouncycastle.crypto.tls.TlsProtocol;
import org.bouncycastle.crypto.tls.TlsServerProtocol;
import org.junit.Assert;
import org.junit.Test;

public class BouncyCastleTlsProtocolTest {

    private static final Logger LOG = LogManager.getLogger();

    private final TlsProtocol protocol = new TlsServerProtocol(null);
    private final Random random = new Random();

    @Test(expected = IOException.class)
    public void tlsProtocolTest() throws IOException {
      byte[] bytes;
      for (int i = 0; i < 1000; i++) {
        bytes = new byte[3];
        this.random.nextBytes(bytes);
        this.protocol.offerInput(bytes);
      }
    }
}

from bc-java.

Hello BC team, this is still an issue for me. @peterdettman was right, I do use org.bouncycastle.crypto.tls.TlsProtocol.offerInput(byte[]) to offer my received data to the TLS protocol. But I really do not understand, what @peterdettman means with his hint on "passing a fixed buffer to each call" is a problem. Can someone please explain this to me? How can the input byte array not be a fixed buffer? How is this method supposed to be used? I read all the tests and javadoc but I just don't get it - sorry for this.

from bc-java.

I found the reason of my problem. Example: if the 4th and 5th byte are set to 0xFF the TLS protocol calculates a total length of 65540 bytes for the first TLS record. Only after actually receiving 65540 bytes TLS protocol goest into safeReadRecord(); which then throws an exception.
I expected TLS protocol to be more strict. I expected you can not send any non-TLS data to TLS protocol without instant termination. What do you think about this? Is it worth changing?

from bc-java.

So I can see now the problem that TlsProtocol.offerInput is not applying the same immediate checks to the TLS record header fields (once it has them) that RecordStream does. We will fix this aspect.

I'm still unclear if you meant something more than that by "strict".

from bc-java.

Yes @peterdettman, with "strict" I just meant an earlier check of received data against protocol specifications. Thank you for your quick reply and the fixing notice.

from bc-java.

Fixed in our git, should be mirrored here soon.

Basically, if we don't yet have a full record, but we do have the full record header, then we will validate the header fields. This matches the behaviour of blocking-mode.

from bc-java.