[openssl-users] decrypt error

[Hubert Kario]

On Thursday, 24 January 2019 12:00:03 CET Scharfenberg, Carsten wrote:
> Thanks for your answer, Matt.
> 
> Obviously the issue is caused by the server.

the issue still could be in a client and it was just exposed by the new, more 
strict server behaviour
 
> Currently I have two servers:
> 1. The legacy server running IIS
> 2. The new server running HAProxy
> I also have two clients:
> 1. the actual hardware client equipped with a hardware security module
> 2. curl using a client certificate that I have created according to the
> procedure that is used for the hardware device above
> 
> Now the picture is: both clients work with the legacy server but none of
> them work with the new HAProxy server.
> 
> BTW: if you have a detailed look at my provided pcap you will notice that
> the client certificate is expired. I've fixed this - without change in the
> outcom.
> 
> Regards,
> Carsten
> 
> On 24/01/2019 09:19, Scharfenberg, Carsten wrote:
> > Hello everybody,
> >  
> > I've just joined this group because I hope you guys can help me with my
> > problem. 
> > I'm using haproxy 1.8.17 and openssl 1.1.1a from Debian testing to serve
> > TLS 1.2 connections with client authentication.
> > The TLS handshake runs through fine. But then the server answers with a
> > Decrypt Error Alert to the Finish message sent by the client.
> 
> What is the client? Is this also OpenSSL (and if so which version), or is it
> something else?
> 
> > How would I debug this error?
> > Is it possible that something is wrong with my certificates?
> 
> That seems unlikely. If there was something wrong with the certificates I
> would have expected the handshake to fail before the point that it gets to.
> >  
> > I've had a look into the source code. Unfortunately it's not so easy to
> > read. It seems to me the alert is generated here:
> > ssl\statem\statem_lib.c:809 in function 'tls_process_finished' when the
> > comparison of 'pkt' and 's->s3->tmp.peer_finish_md' fails.
> > Unfortunately I currently do not know what this means.
> 
> As each endpoint sends and receives handshake messages they both digest the
> contents of those messages. The last step in the process is for each
> endpoint to compare the digests that they created. They should be the same.
> If they are different then that indicates that something has changed
> between one endpoint sending one of those messages and its peer receiving
> it. This could in theory be an active attacker. More likely though it could
> be due to some form of corruption taking place somewhere. Some ideas as to
> the source of a possible corruption:
> 
> - client application bug
> - server application bug
> - client TLS library bug
> - server TLS library bug
> - network "middlebox" corruption
> 
> I'd start by trying to isolate whether the problem is on the client side,
> the server side, or the network. e.g. if the client is on the same host as
> the server does the issue occur? Can you connect from a different client
> (different application and/or different library or library version). Can
> the client connect to other servers successfully.
> 
> Matt


-- 
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 115, 612 00  Brno, Czech Republic
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part.
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20190124/7aef2fc5/attachment.sig>