Hi,

Having recently used stunnel on the phone as a server to encrypt the communication between an external client and a simple TCP server socket on the phone, one of the clients have raised the following….

Phone resets a TLS conection from client, when CBC protection is enabled on tomcat server.

The phone syslog shows:
Oct 28 14:26:14 10 user.crit syslog: CommsChannelExtenderRx(28881): ./src/CommsChannelExtenderRx.cpp:186 Header section invalid

To prevent a SSL/TLS BEAST attack (CVE-2011-3389) Oracle Java (JSSE) has implemented a CBC protection which can be set with System Property jsse.enableCBCProtection. The default value is true.

What was done:

Start client and connect it with a phone.
The TLS connection is established, but then the phone resets the connection, and client is not working.

When I set jsse.enableCBCProtection to false at the tomcat server, the phone accepts the connection and client is working.

To prevent man-in-the-middle attacks, the phone should be able to handle the fragmented TLS block when CBC protection is activated on the client tomcat server.

 

 

I have been unable to find the appropriate stunnel configuration item to support this.

Please could you inform me how this is handled through stunnel.

 

Thank you for your assistance and I look forward to your responses.

 

Thanks..

John

 

 

John Simner BSc(Hons) MSc CEng. MIET

Software Engineer

 

Unify Enterprise Communications Ltd.

Devices Development

 

K Block, Technology Drive, Beeston, Nottingham, NG9 1LA

 

Tel.: +44 (0) 19088 17378

Email: [email protected]

 

www.unify.co.uk

 

Follow us: Social_media_icons 

 

Unify Enterprise Communications Limited. Registered Office: Brickhill Street, Willen Lake, Milton Keynes, MK15 0DJ

Registered No: 5903714, England.

 

This email contains confidential information and is for the exclusive use of the addressee.

If you are not the addressee then any distribution, copying, or use of this email is prohibited.

If received in error, please advise the sender and delete immediately. We accept no liability for
any loss or damage suffered by any person arising from use of this email.