server key exchange signature behavior

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

server key exchange signature behavior

Bruce Cloutier
Hello,

We administer a server (Windows) with a Bitnami stack for a Wordpress
implementation and that uses Apache Httpd and OpenSSL. Separately I am
developing the TLS ECC aspect of a controller device implementation and
note a problematic behavior with the server_key_exchange for ECDHE_RSA.
The developed device ECDHE_RSA suite works properly and as expected with
all of the other servers thus far tested. There is likely a
configuration issue with this Apache installation and I am fishing for a
hint.

The issue is that the RSA signature as part of the server_key_exchange
does not decrypt with the supplied certificate public RSA key. It does
indicate an rsa_pkcs1_sha256 signature.

With a fresh Bitnami install that still uses the default key and
certificate files, the protocol provides a valid digital signature. When
we change the server's certificate (and confirm this with the browser)
the server_key_exchange signature no longer validates. It is as if the
server continues to use the default key for the signature. I have not
tried to confirm that specific point.

My immediate question for someone close to the code is where does
Apache/OpenSSL look for the key file for this signature at this point in
the protocol?

I am hoping that there is just some additional configuration location
that needs to be given our new key file and/or certificate. Can anyone
confirm?

We noted this concern on a production server. We then installed the
stack on a different machine to confirm the fresh install operation. In
adding different key and certificate files we confirm that the signature
then fails. If I ignore the bad signature the secure communications
succeed.

I have been searching the net for this issue for weeks. That has been
fruitless. So I am turning to this list.

Bruce



--
Sent using Thunderbird on Ubuntu 16.04LTS





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

Re: server key exchange signature behavior

Jan Just Keijser-2
Hi,

see comments/questions inline

On 23/06/20 14:03, Bruce Cloutier wrote:

> Hello,
>
> We administer a server (Windows) with a Bitnami stack for a Wordpress
> implementation and that uses Apache Httpd and OpenSSL. Separately I am
> developing the TLS ECC aspect of a controller device implementation and
> note a problematic behavior with the server_key_exchange for ECDHE_RSA.
> The developed device ECDHE_RSA suite works properly and as expected with
> all of the other servers thus far tested. There is likely a
> configuration issue with this Apache installation and I am fishing for a
> hint.
you mention TLS ECC, suggesting Elliptic Curve Crypto, which might
indicate EC-encoded certificates as well, yet talk about ECDHE_RSA which
is Elliptic-curve Diffie-Hellman Exchange with RSA  (for which you'd
normally use RSA-encoded certificates.

Now you can use both with httpd+openssl but you do need to specify the
right certificate (or certificates) when configuring mod_ssl - you can
even concatenate the RSA-signed certificate and the EC-signed
certificate in a single hostcert.pem and mod_ssl will pick up both ,
simply using


#   Server Certificate:
# Point SSLCertificateFile at a PEM encoded certificate.  If
# the certificate is encrypted, then you will be prompted for a
# pass phrase.  Note that a kill -HUP will prompt again.  A new
# certificate can be generated using the genkey(1) command.
SSLCertificateFile /etc/httpd/certs/hostcert.pem

#    Server Private Key:
#   If the key is not combined with the certificate, use this
#   directive to point at the key file.  Keep in mind that if
#   you've both a RSA and a DSA private key you can configure
#   both in parallel (to also allow the use of DSA ciphers, etc.)
SSLCertificateKeyFile /etc/httpd/certs/hostkey.pem


I'd recommend to take your test cert+key and see if you can run it using
   openssl s_server  <parms>
against
   openssl s_client <parms>

(use 'openssl s_server -help' and 'openssl s_client -help' for the
parameter list).

If *that* works and apache+mod_ssl does not then you're looking at an
mod_ssl configuration issue.

HTH,

JJK



> The issue is that the RSA signature as part of the server_key_exchange
> does not decrypt with the supplied certificate public RSA key. It does
> indicate an rsa_pkcs1_sha256 signature.
>
> With a fresh Bitnami install that still uses the default key and
> certificate files, the protocol provides a valid digital signature. When
> we change the server's certificate (and confirm this with the browser)
> the server_key_exchange signature no longer validates. It is as if the
> server continues to use the default key for the signature. I have not
> tried to confirm that specific point.
>
> My immediate question for someone close to the code is where does
> Apache/OpenSSL look for the key file for this signature at this point in
> the protocol?
>
> I am hoping that there is just some additional configuration location
> that needs to be given our new key file and/or certificate. Can anyone
> confirm?
>
> We noted this concern on a production server. We then installed the
> stack on a different machine to confirm the fresh install operation. In
> adding different key and certificate files we confirm that the signature
> then fails. If I ignore the bad signature the secure communications
> succeed.
>
> I have been searching the net for this issue for weeks. That has been
> fruitless. So I am turning to this list.
>
>

Reply | Threaded
Open this post in threaded view
|

Re: server key exchange signature behavior

Bruce Cloutier
In reply to this post by Bruce Cloutier
Has anyone thought about this question? The site is https://jnior.com if
anyone wants to hit it. For me the digital signature in the
server_key_exchange does not verify. Is there a site diagnostic that
might report on this? I suspect that we have not fully configured the
change in certificates. Has us stumped. Could really use a hint.

On 6/23/20 8:03 AM, Bruce Cloutier wrote:

> Hello,
>
> We administer a server (Windows) with a Bitnami stack for a Wordpress
> implementation and that uses Apache Httpd and OpenSSL. Separately I am
> developing the TLS ECC aspect of a controller device implementation and
> note a problematic behavior with the server_key_exchange for ECDHE_RSA.
> The developed device ECDHE_RSA suite works properly and as expected with
> all of the other servers thus far tested. There is likely a
> configuration issue with this Apache installation and I am fishing for a
> hint.
>
> The issue is that the RSA signature as part of the server_key_exchange
> does not decrypt with the supplied certificate public RSA key. It does
> indicate an rsa_pkcs1_sha256 signature.
>
> With a fresh Bitnami install that still uses the default key and
> certificate files, the protocol provides a valid digital signature. When
> we change the server's certificate (and confirm this with the browser)
> the server_key_exchange signature no longer validates. It is as if the
> server continues to use the default key for the signature. I have not
> tried to confirm that specific point.
>
> My immediate question for someone close to the code is where does
> Apache/OpenSSL look for the key file for this signature at this point in
> the protocol?
>
> I am hoping that there is just some additional configuration location
> that needs to be given our new key file and/or certificate. Can anyone
> confirm?
>
> We noted this concern on a production server. We then installed the
> stack on a different machine to confirm the fresh install operation. In
> adding different key and certificate files we confirm that the signature
> then fails. If I ignore the bad signature the secure communications
> succeed.
>
> I have been searching the net for this issue for weeks. That has been
> fruitless. So I am turning to this list.
>
> Bruce
>
>
>
--
Sent using Thunderbird on Ubuntu 16.04LTS



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

RE: server key exchange signature behavior

Michael Wojcik
> From: openssl-users [mailto:[hidden email]] On Behalf Of
> Bruce Cloutier
> Sent: Thursday, June 25, 2020 10:11
>
> Has anyone thought about this question?

From your description, it sounds like an Apache issue, not an OpenSSL one. I don't know enough about Apache configuration to comment. (I've configured a few Apache instances in my day, but never had any real issues with it, so I've never done more than search the docs for what I needed and implemented it.)

> The site is https://jnior.com if
> anyone wants to hit it. For me the digital signature in the
> server_key_exchange does not verify.

I just tried openssl s_client, and it didn't complain about anything. Negotiated a TLSv1.2 session with ECDHE-RSA-AES256-GCM-SHA384 and verified the chain.

--
Michael Wojcik
Distinguished Engineer, Micro Focus



Reply | Threaded
Open this post in threaded view
|

Re: server key exchange signature behavior

Bruce Cloutier
Yeah. I doubt it is an OpenSSL issue directly as Apache might be feeding
the wrong key. Just need confirmation that there isn't a default key
configuration setting for OpenSSL that might be taking precedence for
who knows why.

I can connect successfully with the browser so I cannot rule out that my
TLS implementation is faulty. However, it validates with every other
site and it validates with the default install of this bitnami stack.
Once we reconfigure for the new key and certificate, this signature in
the server_key_exchange message fails. Nothing else seems to complain.
My code does, well, because I know that I actually do verify that
signature against the supplied certificate.

So to everyone else it appears that we have configured the new
certificates properly (manually achieved Let's Encrypt cert). If OpenSSL
fails to validate this particular digital signature that would be the
case. If in my TLS implementation I skip this check (actually now I just
post a warning) everything negotiates and proceeds just fine.

Obviously, THAT signature is there for a reason. I should expect if to
validate. Just don't know what key it is using?

I am not sure how to get to the Apache people or, might be, the Bitnami
folks?

Bruce

On 6/25/20 12:07 PM, Michael Wojcik wrote:

>> From: openssl-users [mailto:[hidden email]] On Behalf Of
>> Bruce Cloutier
>> Sent: Thursday, June 25, 2020 10:11
>>
>> Has anyone thought about this question?
> From your description, it sounds like an Apache issue, not an OpenSSL one. I don't know enough about Apache configuration to comment. (I've configured a few Apache instances in my day, but never had any real issues with it, so I've never done more than search the docs for what I needed and implemented it.)
>
>> The site is https://jnior.com if
>> anyone wants to hit it. For me the digital signature in the
>> server_key_exchange does not verify.
> I just tried openssl s_client, and it didn't complain about anything. Negotiated a TLSv1.2 session with ECDHE-RSA-AES256-GCM-SHA384 and verified the chain.
>
> --
> Michael Wojcik
> Distinguished Engineer, Micro Focus
>
>
>
--
Sent using Thunderbird on Ubuntu 16.04LTS



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

Re: server key exchange signature behavior

Bruce Cloutier
Sorry,

By "If OpenSSL fails to validate this particular digital signature that
would be the case." I meant to question whether or not OpenSSL is in
fact doing the validation? In the case that the signature is being
ignored then clients wouldn't complain. They wouldn't notice.

Bruce

On 6/25/20 1:04 PM, Bruce Cloutier wrote:

> Yeah. I doubt it is an OpenSSL issue directly as Apache might be feeding
> the wrong key. Just need confirmation that there isn't a default key
> configuration setting for OpenSSL that might be taking precedence for
> who knows why.
>
> I can connect successfully with the browser so I cannot rule out that my
> TLS implementation is faulty. However, it validates with every other
> site and it validates with the default install of this bitnami stack.
> Once we reconfigure for the new key and certificate, this signature in
> the server_key_exchange message fails. Nothing else seems to complain.
> My code does, well, because I know that I actually do verify that
> signature against the supplied certificate.
>
> So to everyone else it appears that we have configured the new
> certificates properly (manually achieved Let's Encrypt cert). If OpenSSL
> fails to validate this particular digital signature that would be the
> case. If in my TLS implementation I skip this check (actually now I just
> post a warning) everything negotiates and proceeds just fine.
>
> Obviously, THAT signature is there for a reason. I should expect if to
> validate. Just don't know what key it is using?
>
> I am not sure how to get to the Apache people or, might be, the Bitnami
> folks?
>
> Bruce
>
> On 6/25/20 12:07 PM, Michael Wojcik wrote:
>>> From: openssl-users [mailto:[hidden email]] On Behalf Of
>>> Bruce Cloutier
>>> Sent: Thursday, June 25, 2020 10:11
>>>
>>> Has anyone thought about this question?
>> From your description, it sounds like an Apache issue, not an OpenSSL one. I don't know enough about Apache configuration to comment. (I've configured a few Apache instances in my day, but never had any real issues with it, so I've never done more than search the docs for what I needed and implemented it.)
>>
>>> The site is https://jnior.com if
>>> anyone wants to hit it. For me the digital signature in the
>>> server_key_exchange does not verify.
>> I just tried openssl s_client, and it didn't complain about anything. Negotiated a TLSv1.2 session with ECDHE-RSA-AES256-GCM-SHA384 and verified the chain.
>>
>> --
>> Michael Wojcik
>> Distinguished Engineer, Micro Focus
>>
>>
>>
--
Sent using Thunderbird on Ubuntu 16.04LTS



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

Re: server key exchange signature behavior

OpenSSL - User mailing list
You may also check out the results of the popular ssllabs.com test here:

https://www.ssllabs.com/ssltest/analyze.html?d=jnior.com&hideResults=on

Note however that in recent years they have become quite aggressive in
labeling things as "weak" when they are simply "slightly less than the
best that the latestbig-brand browsers support" with no consideration
for servers that try to provide compatibility for older clients in
addition to the latest hype.

As for the signature on the key exchange in SSL3/TLS1.0/TLS1.1/TLS 1.2
and the final signature in TLS1.3, those are the one signature that
causes the certificates to do anything meaningful, so I would expect all
but the most crappy clients to check it and make a very serious error
message "SOMEONE IS HACKING YOUR CONNECTION, PULL THE PLUG NOW!" or
something equally serious.

On 2020-06-25 19:09, Bruce Cloutier wrote:

> Sorry,
>
> By "If OpenSSL fails to validate this particular digital signature that
> would be the case." I meant to question whether or not OpenSSL is in
> fact doing the validation? In the case that the signature is being
> ignored then clients wouldn't complain. They wouldn't notice.
>
> Bruce
>
> On 6/25/20 1:04 PM, Bruce Cloutier wrote:
>> Yeah. I doubt it is an OpenSSL issue directly as Apache might be feeding
>> the wrong key. Just need confirmation that there isn't a default key
>> configuration setting for OpenSSL that might be taking precedence for
>> who knows why.
>>
>> I can connect successfully with the browser so I cannot rule out that my
>> TLS implementation is faulty. However, it validates with every other
>> site and it validates with the default install of this bitnami stack.
>> Once we reconfigure for the new key and certificate, this signature in
>> the server_key_exchange message fails. Nothing else seems to complain.
>> My code does, well, because I know that I actually do verify that
>> signature against the supplied certificate.
>>
>> So to everyone else it appears that we have configured the new
>> certificates properly (manually achieved Let's Encrypt cert). If OpenSSL
>> fails to validate this particular digital signature that would be the
>> case. If in my TLS implementation I skip this check (actually now I just
>> post a warning) everything negotiates and proceeds just fine.
>>
>> Obviously, THAT signature is there for a reason. I should expect if to
>> validate. Just don't know what key it is using?
>>
>> I am not sure how to get to the Apache people or, might be, the Bitnami
>> folks?
>>
>> Bruce
>>
>> On 6/25/20 12:07 PM, Michael Wojcik wrote:
>>>> From: openssl-users [mailto:[hidden email]] On Behalf Of
>>>> Bruce Cloutier
>>>> Sent: Thursday, June 25, 2020 10:11
>>>>
>>>> Has anyone thought about this question?
>>>  From your description, it sounds like an Apache issue, not an OpenSSL one. I don't know enough about Apache configuration to comment. (I've configured a few Apache instances in my day, but never had any real issues with it, so I've never done more than search the docs for what I needed and implemented it.)
>>>
>>>> The site is https://jnior.com if
>>>> anyone wants to hit it. For me the digital signature in the
>>>> server_key_exchange does not verify.
>>> I just tried openssl s_client, and it didn't complain about anything. Negotiated a TLSv1.2 session with ECDHE-RSA-AES256-GCM-SHA384 and verified the chain.
>>>

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

Reply | Threaded
Open this post in threaded view
|

RE: server key exchange signature behavior

Michael Wojcik
In reply to this post by Bruce Cloutier
> From: openssl-users [mailto:[hidden email]] On Behalf Of
> Bruce Cloutier
> Sent: Thursday, June 25, 2020 12:10
>
> By "If OpenSSL fails to validate this particular digital signature that
> would be the case." I meant to question whether or not OpenSSL is in
> fact doing the validation? In the case that the signature is being
> ignored then clients wouldn't complain. They wouldn't notice.

s_client should be verifying the signature.[1] That is, it should be verifying every signature that's part of the actual TLS protocol. I admit it's not entirely clear to me which signature isn't being verified successfully by your client.


[1] I'm not sure "validate" is the proper term here, technically speaking. In my experience, the literature usually uses "verify" for confirming a signature. "Validate" is generally used for more complex protocols, such as certificate validation, which involves a large number of steps with various types of checks.

--
Michael Wojcik
Distinguished Engineer, Micro Focus



Reply | Threaded
Open this post in threaded view
|

Re: server key exchange signature behavior

Bruce Cloutier
I agree that I am not being explicit regarding my terminology. I don't
mean to confuse. I just cannot get anywhere on this in a vacuum. So, I
need to reach out.

Specifically, the Signature covering the EC Diffe-Hellman Server Params
in the server_key_exchange message that I eventually receive in making
an outgoing client connection from my TLS implementation, does not
decrypt into a valid PKCS1 ASN.1 structure (or anything recognizable).
That is happening with this one server installation using Apache in a
Bitnami stack (Windows machine). My TLS code is running as part of the
operating system on our separate single board computer controller (JNIOR).

I use the public key extracted from the supplied certificate to decrypt
and then compare the calculated hash. This procedure has been successful
(and signatures verify/validate/match) in every other connection attempt
to other servers (including google.com). It also works with this Apache
server before we move away from the default key and certificate files.
Basically, our server is using some other key for this. Maybe still the
default. After we point configuration to a new certificate and key.

Yeah, I had at first thought that there was an intrusion. But in testing
with a clean sandboxed server we see the same results. Yes, it is most
likely an Apache configuration issue but, we've dug through all of that
and nothing jumps out.

So either we haven't configured every possible corner of this Apache
server correctly, or there is some odd extension to TLS that I've
missed. But as you all know, debugging in this area is difficult.

jnior.com is obviously public and we need to know if we have it
improperly configured. But, I need to know why in this one instance my
TLS implementation fails. In either case, it is an symptom that
shouldn't be ignored as you would agree.

The good news is that if there were an OpenSSL bug somewhat associated
with this, you all would have already mentioned it (I assume).

Bruce

On 6/25/20 1:32 PM, Michael Wojcik wrote:

>> From: openssl-users [mailto:[hidden email]] On Behalf Of
>> Bruce Cloutier
>> Sent: Thursday, June 25, 2020 12:10
>>
>> By "If OpenSSL fails to validate this particular digital signature that
>> would be the case." I meant to question whether or not OpenSSL is in
>> fact doing the validation? In the case that the signature is being
>> ignored then clients wouldn't complain. They wouldn't notice.
> s_client should be verifying the signature.[1] That is, it should be verifying every signature that's part of the actual TLS protocol. I admit it's not entirely clear to me which signature isn't being verified successfully by your client.
>
>
> [1] I'm not sure "validate" is the proper term here, technically speaking. In my experience, the literature usually uses "verify" for confirming a signature. "Validate" is generally used for more complex protocols, such as certificate validation, which involves a large number of steps with various types of checks.
>
> --
> Michael Wojcik
> Distinguished Engineer, Micro Focus
>
>
>
--
Sent using Thunderbird on Ubuntu 16.04LTS



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

Re: server key exchange signature behavior

Jan Just Keijser-2
On 25/06/20 20:02, Bruce Cloutier wrote:

> I agree that I am not being explicit regarding my terminology. I don't
> mean to confuse. I just cannot get anywhere on this in a vacuum. So, I
> need to reach out.
>
> Specifically, the Signature covering the EC Diffe-Hellman Server Params
> in the server_key_exchange message that I eventually receive in making
> an outgoing client connection from my TLS implementation, does not
> decrypt into a valid PKCS1 ASN.1 structure (or anything recognizable).
> That is happening with this one server installation using Apache in a
> Bitnami stack (Windows machine). My TLS code is running as part of the
> operating system on our separate single board computer controller (JNIOR).
>
> I use the public key extracted from the supplied certificate to decrypt
> and then compare the calculated hash. This procedure has been successful
> (and signatures verify/validate/match) in every other connection attempt
> to other servers (including google.com). It also works with this Apache
> server before we move away from the default key and certificate files.
> Basically, our server is using some other key for this. Maybe still the
> default. After we point configuration to a new certificate and key.
>
> Yeah, I had at first thought that there was an intrusion. But in testing
> with a clean sandboxed server we see the same results. Yes, it is most
> likely an Apache configuration issue but, we've dug through all of that
> and nothing jumps out.
>
> So either we haven't configured every possible corner of this Apache
> server correctly, or there is some odd extension to TLS that I've
> missed. But as you all know, debugging in this area is difficult.
>
> jnior.com is obviously public and we need to know if we have it
> improperly configured. But, I need to know why in this one instance my
> TLS implementation fails. In either case, it is an symptom that
> shouldn't be ignored as you would agree.
>
> The good news is that if there were an OpenSSL bug somewhat associated
> with this, you all would have already mentioned it (I assume).
>

I'd suggest to run something like wireshark and capture the TLS
handshake - if I do that against jnior.com I see that the jnior.com
certificate has a X509 cert extension unknown to my rather old Wireshark
version, but that should not matter much. Wireshark will give you
detailed info about the EC Diffie-Hellman Server Params that were sent
over the wire, including the signature. Wireshark does not indicate any
problems there, although I am not sure if it *would* , if there was a
problem.

However, it will give you an easy method to see what wireshark thinks
the signature is compared to what your code thinks the signature is.

As a side-remark: I did notice your server cert is using 3072 bit RSA
whereas the CAs are based on 2048bit RSA - nothing wrong with that, but
do make sure your code can handle that (under normal circumstances it
would not be an issue).

HTH,

JJK

> On 6/25/20 1:32 PM, Michael Wojcik wrote:
>>> From: openssl-users [mailto:[hidden email]] On Behalf Of
>>> Bruce Cloutier
>>> Sent: Thursday, June 25, 2020 12:10
>>>
>>> By "If OpenSSL fails to validate this particular digital signature that
>>> would be the case." I meant to question whether or not OpenSSL is in
>>> fact doing the validation? In the case that the signature is being
>>> ignored then clients wouldn't complain. They wouldn't notice.
>> s_client should be verifying the signature.[1] That is, it should be verifying every signature that's part of the actual TLS protocol. I admit it's not entirely clear to me which signature isn't being verified successfully by your client.
>>
>>
>> [1] I'm not sure "validate" is the proper term here, technically speaking. In my experience, the literature usually uses "verify" for confirming a signature. "Validate" is generally used for more complex protocols, such as certificate validation, which involves a large number of steps with various types of checks.
>>
>> --
>> Michael Wojcik
>> Distinguished Engineer, Micro Focus
>>
>>
>>

Reply | Threaded
Open this post in threaded view
|

Re: server key exchange signature behavior

Bruce Cloutier
Jan,

Use Wireshark all of the time. In fact I've used it since before it was
Wireshark. But now... I can't remember what it was called before. Great
tool.

You, though, may have hit on something in pointing out the 3072 bit key.
I will check on that. It was a design decision in developing this
controller that no 3rd party code be used. Consequently I have authored
every byte of the OS including the stack. So the multi-precision math is
all mine and... it does have a limit. I may have set it with the 2,048
bit keys in mind. This would absolutely fit with the symptoms. Let me
verify.

Thank you!

Bruce

On 6/26/20 3:52 AM, Jan Just Keijser wrote:

> On 25/06/20 20:02, Bruce Cloutier wrote:
>> I agree that I am not being explicit regarding my terminology. I don't
>> mean to confuse. I just cannot get anywhere on this in a vacuum. So, I
>> need to reach out.
>>
>> Specifically, the Signature covering the EC Diffe-Hellman Server Params
>> in the server_key_exchange message that I eventually receive in making
>> an outgoing client connection from my TLS implementation, does not
>> decrypt into a valid PKCS1 ASN.1 structure (or anything recognizable).
>> That is happening with this one server installation using Apache in a
>> Bitnami stack (Windows machine). My TLS code is running as part of the
>> operating system on our separate single board computer controller
>> (JNIOR).
>>
>> I use the public key extracted from the supplied certificate to decrypt
>> and then compare the calculated hash. This procedure has been successful
>> (and signatures verify/validate/match) in every other connection attempt
>> to other servers (including google.com). It also works with this Apache
>> server before we move away from the default key and certificate files.
>> Basically, our server is using some other key for this. Maybe still the
>> default. After we point configuration to a new certificate and key.
>>
>> Yeah, I had at first thought that there was an intrusion. But in testing
>> with a clean sandboxed server we see the same results. Yes, it is most
>> likely an Apache configuration issue but, we've dug through all of that
>> and nothing jumps out.
>>
>> So either we haven't configured every possible corner of this Apache
>> server correctly, or there is some odd extension to TLS that I've
>> missed. But as you all know, debugging in this area is difficult.
>>
>> jnior.com is obviously public and we need to know if we have it
>> improperly configured. But, I need to know why in this one instance my
>> TLS implementation fails. In either case, it is an symptom that
>> shouldn't be ignored as you would agree.
>>
>> The good news is that if there were an OpenSSL bug somewhat associated
>> with this, you all would have already mentioned it (I assume).
>>
>
> I'd suggest to run something like wireshark and capture the TLS
> handshake - if I do that against jnior.com I see that the jnior.com
> certificate has a X509 cert extension unknown to my rather old
> Wireshark version, but that should not matter much. Wireshark will
> give you detailed info about the EC Diffie-Hellman Server Params that
> were sent over the wire, including the signature. Wireshark does not
> indicate any problems there, although I am not sure if it *would* , if
> there was a problem.
>
> However, it will give you an easy method to see what wireshark thinks
> the signature is compared to what your code thinks the signature is.
>
> As a side-remark: I did notice your server cert is using 3072 bit RSA
> whereas the CAs are based on 2048bit RSA - nothing wrong with that,
> but do make sure your code can handle that (under normal circumstances
> it would not be an issue).
>
> HTH,
>
> JJK
>
>> On 6/25/20 1:32 PM, Michael Wojcik wrote:
>>>> From: openssl-users [mailto:[hidden email]] On
>>>> Behalf Of
>>>> Bruce Cloutier
>>>> Sent: Thursday, June 25, 2020 12:10
>>>>
>>>> By "If OpenSSL fails to validate this particular digital signature
>>>> that
>>>> would be the case." I meant to question whether or not OpenSSL is in
>>>> fact doing the validation? In the case that the signature is being
>>>> ignored then clients wouldn't complain. They wouldn't notice.
>>> s_client should be verifying the signature.[1] That is, it should be
>>> verifying every signature that's part of the actual TLS protocol. I
>>> admit it's not entirely clear to me which signature isn't being
>>> verified successfully by your client.
>>>
>>>
>>> [1] I'm not sure "validate" is the proper term here, technically
>>> speaking. In my experience, the literature usually uses "verify" for
>>> confirming a signature. "Validate" is generally used for more
>>> complex protocols, such as certificate validation, which involves a
>>> large number of steps with various types of checks.
>>>
>>> --
>>> Michael Wojcik
>>> Distinguished Engineer, Micro Focus
>>>
>>>
>>>
>
>
>
--
Sent using Thunderbird on Ubuntu 16.04LTS



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

Re: server key exchange signature behavior

Bruce Cloutier
Thank you JJK and everyone!!

Jan, that was it! Never thought to check the key size. Just too close to
it I guess. I could handle the 2,048 bit keys but set a fixed maximum
register size of 4,096 bits. Well, it needs 6,144 bits to do the 3,072
bit math. My bad as they say. I do have a ToDo in the comments to
implement dynamic sizing. After all, my target is just a
micro-controller based device at 100 MHz. Security needs to be
functional and, well, not necessarily strong. Most neglect to move away
from default passwords. Ugh.

I'll probably roll jnior.com back to 2,048. I did not purposely set the
larger key size. Must have been someone's idea of a good default.

Oh... and it was Ethereal before Wireshark. I had to look it up.
Starting to get concerned about my memory. But, I do have valid 30-year
old backups of past systems and am certain I can I actually pull a
version off that if I really wanted.

I was just adding Elliptic Curve capabilities to my TLS as something to
do during this pandemic. Yeah, finally. It is an academic endeavor in
keeping with my DIY edict.

Thank you all. And, Jan you are a star!!

Bruce

On 6/26/20 6:23 AM, Bruce Cloutier wrote:

> Jan,
>
> Use Wireshark all of the time. In fact I've used it since before it was
> Wireshark. But now... I can't remember what it was called before. Great
> tool.
>
> You, though, may have hit on something in pointing out the 3072 bit key.
> I will check on that. It was a design decision in developing this
> controller that no 3rd party code be used. Consequently I have authored
> every byte of the OS including the stack. So the multi-precision math is
> all mine and... it does have a limit. I may have set it with the 2,048
> bit keys in mind. This would absolutely fit with the symptoms. Let me
> verify.
>
> Thank you!
>
> Bruce
>
> On 6/26/20 3:52 AM, Jan Just Keijser wrote:
>> On 25/06/20 20:02, Bruce Cloutier wrote:
>>> I agree that I am not being explicit regarding my terminology. I don't
>>> mean to confuse. I just cannot get anywhere on this in a vacuum. So, I
>>> need to reach out.
>>>
>>> Specifically, the Signature covering the EC Diffe-Hellman Server Params
>>> in the server_key_exchange message that I eventually receive in making
>>> an outgoing client connection from my TLS implementation, does not
>>> decrypt into a valid PKCS1 ASN.1 structure (or anything recognizable).
>>> That is happening with this one server installation using Apache in a
>>> Bitnami stack (Windows machine). My TLS code is running as part of the
>>> operating system on our separate single board computer controller
>>> (JNIOR).
>>>
>>> I use the public key extracted from the supplied certificate to decrypt
>>> and then compare the calculated hash. This procedure has been successful
>>> (and signatures verify/validate/match) in every other connection attempt
>>> to other servers (including google.com). It also works with this Apache
>>> server before we move away from the default key and certificate files.
>>> Basically, our server is using some other key for this. Maybe still the
>>> default. After we point configuration to a new certificate and key.
>>>
>>> Yeah, I had at first thought that there was an intrusion. But in testing
>>> with a clean sandboxed server we see the same results. Yes, it is most
>>> likely an Apache configuration issue but, we've dug through all of that
>>> and nothing jumps out.
>>>
>>> So either we haven't configured every possible corner of this Apache
>>> server correctly, or there is some odd extension to TLS that I've
>>> missed. But as you all know, debugging in this area is difficult.
>>>
>>> jnior.com is obviously public and we need to know if we have it
>>> improperly configured. But, I need to know why in this one instance my
>>> TLS implementation fails. In either case, it is an symptom that
>>> shouldn't be ignored as you would agree.
>>>
>>> The good news is that if there were an OpenSSL bug somewhat associated
>>> with this, you all would have already mentioned it (I assume).
>>>
>> I'd suggest to run something like wireshark and capture the TLS
>> handshake - if I do that against jnior.com I see that the jnior.com
>> certificate has a X509 cert extension unknown to my rather old
>> Wireshark version, but that should not matter much. Wireshark will
>> give you detailed info about the EC Diffie-Hellman Server Params that
>> were sent over the wire, including the signature. Wireshark does not
>> indicate any problems there, although I am not sure if it *would* , if
>> there was a problem.
>>
>> However, it will give you an easy method to see what wireshark thinks
>> the signature is compared to what your code thinks the signature is.
>>
>> As a side-remark: I did notice your server cert is using 3072 bit RSA
>> whereas the CAs are based on 2048bit RSA - nothing wrong with that,
>> but do make sure your code can handle that (under normal circumstances
>> it would not be an issue).
>>
>> HTH,
>>
>> JJK
>>
>>> On 6/25/20 1:32 PM, Michael Wojcik wrote:
>>>>> From: openssl-users [mailto:[hidden email]] On
>>>>> Behalf Of
>>>>> Bruce Cloutier
>>>>> Sent: Thursday, June 25, 2020 12:10
>>>>>
>>>>> By "If OpenSSL fails to validate this particular digital signature
>>>>> that
>>>>> would be the case." I meant to question whether or not OpenSSL is in
>>>>> fact doing the validation? In the case that the signature is being
>>>>> ignored then clients wouldn't complain. They wouldn't notice.
>>>> s_client should be verifying the signature.[1] That is, it should be
>>>> verifying every signature that's part of the actual TLS protocol. I
>>>> admit it's not entirely clear to me which signature isn't being
>>>> verified successfully by your client.
>>>>
>>>>
>>>> [1] I'm not sure "validate" is the proper term here, technically
>>>> speaking. In my experience, the literature usually uses "verify" for
>>>> confirming a signature. "Validate" is generally used for more
>>>> complex protocols, such as certificate validation, which involves a
>>>> large number of steps with various types of checks.
>>>>
>>>> --
>>>> Michael Wojcik
>>>> Distinguished Engineer, Micro Focus
>>>>
>>>>
>>>>
>>
>>
--
Sent using Thunderbird on Ubuntu 16.04LTS



signature.asc (235 bytes) Download Attachment