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:openssl-users-bounces at openssl.org] 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


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: OpenPGP digital signature
URL: <https://mta.openssl.org/pipermail/openssl-users/attachments/20200626/71d68a17/attachment.sig>