decrypt error

classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|

decrypt error

Scharfenberg, Carsten
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.
How would I debug this error?
Is it possible that something is wrong with my certificates?
 
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.
 
For detailed information I’ve appended a pcap file.
 
 
Regards,
C. Scharfenberg
 

--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

decrpyt_error.pcap (9K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: decrypt error

Matt Caswell-2


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
Reply | Threaded
Open this post in threaded view
|

Re: decrypt error

Scharfenberg, Carsten
In reply to this post by Scharfenberg, Carsten
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
Reply | Threaded
Open this post in threaded view
|

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

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: decrypt error

Matt Caswell-2
In reply to this post by Scharfenberg, Carsten


On 24/01/2019 11:00, Scharfenberg, Carsten wrote:

> 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.

Hmmm. It's possible that it is still a client issue if the negotiated
extensions/ciphersuite/protocol version etc differ between the connection for
the old server and the new server. You might want to experiment with different
ciphersuite/group/sigalgs etc settings on the server to see if there is
sensitivity there to this issue.

Matt



>
> 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
Reply | Threaded
Open this post in threaded view
|

Re: decrypt error

Matt Caswell-2


On 24/01/2019 15:33, Matt Caswell wrote:

>
>
> On 24/01/2019 11:00, Scharfenberg, Carsten wrote:
>> 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.
>
> Hmmm. It's possible that it is still a client issue if the negotiated
> extensions/ciphersuite/protocol version etc differ between the connection for
> the old server and the new server. You might want to experiment with different
> ciphersuite/group/sigalgs etc settings on the server to see if there is
> sensitivity there to this issue.

Another thought - are connections successful if client auth is NOT used?

Matt

>
> Matt
>
>
>
>>
>> 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
Reply | Threaded
Open this post in threaded view
|

Re: decrypt error

Scharfenberg, Carsten
Yes, it works if I deactivate client auth.
Concerning the cipher: I use one specific cipher on server and on client side. This is the only cipher supported by the actual hardware client.
Concerning the sigalg: I've had big trouble with this because due to bug in the client I need to restrict the sigalgs offered by the server. This is not possible with haproxy. But it is possible with openssl.cnf since version 1.1.1. This is why I've installed haproxy and openssl from Debian testing.
So I'm very confident about the cipher suite and the signature algorithm.

I've just created a new certificate hierarchy. Et voila: it works.
So obviously this issue is certificate-related.
Still I have to figure out what is wrong with the old certificates because I cannot replace them in the productive environment.
My next step will be to create new hierarchy again that matches the original hierarchy as close as possible (including constraints and extensions).

-----Ursprüngliche Nachricht-----
Von: openssl-users [mailto:[hidden email]] Im Auftrag von Matt Caswell
Gesendet: Donnerstag, 24. Januar 2019 16:38
An: [hidden email]
Betreff: Re: [openssl-users] decrypt error



On 24/01/2019 15:33, Matt Caswell wrote:

>
>
> On 24/01/2019 11:00, Scharfenberg, Carsten wrote:
>> 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.
>
> Hmmm. It's possible that it is still a client issue if the negotiated
> extensions/ciphersuite/protocol version etc differ between the connection for
> the old server and the new server. You might want to experiment with different
> ciphersuite/group/sigalgs etc settings on the server to see if there is
> sensitivity there to this issue.

Another thought - are connections successful if client auth is NOT used?

Matt

>
> Matt
>
>
>
>>
>> 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
Reply | Threaded
Open this post in threaded view
|

Re: decrypt error

OpenSSL - User mailing list
Since this seems to be a certificate issue, would it be possible
to make the server log all the certificate checking steps and
errors with the failing certificates.

One obvious test would be to try connecting to the "openssl s_server"
utility with a similar configuration and lots of debug options. Another
would be to install all the debug symbols and running haproxy under a
debugger with strategically set breakpoints to look at the execution stack
when errors are reported or validation occurs.

On 24/01/2019 16:55, Scharfenberg, Carsten wrote:

> Yes, it works if I deactivate client auth.
> Concerning the cipher: I use one specific cipher on server and on client side. This is the only cipher supported by the actual hardware client.
> Concerning the sigalg: I've had big trouble with this because due to bug in the client I need to restrict the sigalgs offered by the server. This is not possible with haproxy. But it is possible with openssl.cnf since version 1.1.1. This is why I've installed haproxy and openssl from Debian testing.
> So I'm very confident about the cipher suite and the signature algorithm.
>
> I've just created a new certificate hierarchy. Et voila: it works.
> So obviously this issue is certificate-related.
> Still I have to figure out what is wrong with the old certificates because I cannot replace them in the productive environment.
> My next step will be to create new hierarchy again that matches the original hierarchy as close as possible (including constraints and extensions).
>

Enjoy

Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded

--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: decrypt error

Scharfenberg, Carsten
Yes, it is a certificate error: a very stupid one.
I've used the wrong CA cert - from a different hierarchy.

I'm sorry for the hassle.
Nevertheless thanks for your support.

Carsten

-----Ursprüngliche Nachricht-----
Von: openssl-users [mailto:[hidden email]] Im Auftrag von Jakob Bohm via openssl-users
Gesendet: Freitag, 25. Januar 2019 02:17
An: [hidden email]
Betreff: Re: [openssl-users] decrypt error

Since this seems to be a certificate issue, would it be possible
to make the server log all the certificate checking steps and
errors with the failing certificates.

One obvious test would be to try connecting to the "openssl s_server"
utility with a similar configuration and lots of debug options. Another
would be to install all the debug symbols and running haproxy under a
debugger with strategically set breakpoints to look at the execution stack
when errors are reported or validation occurs.

On 24/01/2019 16:55, Scharfenberg, Carsten wrote:

> Yes, it works if I deactivate client auth.
> Concerning the cipher: I use one specific cipher on server and on client side. This is the only cipher supported by the actual hardware client.
> Concerning the sigalg: I've had big trouble with this because due to bug in the client I need to restrict the sigalgs offered by the server. This is not possible with haproxy. But it is possible with openssl.cnf since version 1.1.1. This is why I've installed haproxy and openssl from Debian testing.
> So I'm very confident about the cipher suite and the signature algorithm.
>
> I've just created a new certificate hierarchy. Et voila: it works.
> So obviously this issue is certificate-related.
> Still I have to figure out what is wrong with the old certificates because I cannot replace them in the productive environment.
> My next step will be to create new hierarchy again that matches the original hierarchy as close as possible (including constraints and extensions).
>

Enjoy

Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded

--
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