Re: decrypt error

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Thanks for your answer, Matt.

Obviously the issue is caused by the server.

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
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux