server key exchange signature behavior

Fri Jun 26 12:13:35 UTC 2020

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: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/31f0cbbf/attachment-0001.sig>