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@xxxxxxxxxxx] 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
Attachment:
signature.asc
Description: OpenPGP digital signature
