Jump to content


SSL fingerprint does not match, even from localhost

ssl authn ldap security

  • Please log in to reply
3 replies to this topic

#1 saudia

saudia

    Newbie

  • Members
  • Pip
  • 5 posts
  • LocationPittsburgh

Posted 19 August 2019 - 05:40 PM

I generated a new SSL cert on my server today.  Expectedly, the P4V client gave a warning about the cert changing and asked if I wanted to trust the new cert, listing the new cert's fingerprint in the dialog box.

I decided to be a good admin and actually check the fingerprint.

I connected to my server via SSh and ran the openssl commands to get the fingerprints of "certificate.txt" for md5, sha1, and sha256.

None of them matched what P4V gave me.

Then I copied the contents of "certificate.txt" and pasted it into a few different online SSL decoders/checkers.  None of them matched, including using decoders that supported sha224, sha384, and sha512.

Finally, from SSh logged directly into the server, I used the p4 command line client to connect to localhost, and it gave me the same fingerprint that P4V game me on my desktop (which, again, does not match any fingerprint I've gotten by manually decoding with openssl).  So, it does not appear to be a MitM attack.

The only thing left that I can think of is that it's using some other algorithm for the hash.  What is left that is used by SSL?  Are ECDSA or ED25519 used for SSL?  Does anyone actually know what is used? Based on the length of the fingerprint it appears to SHA-1.

Otherwise, I seem to have a potential security problem.

#2 Miles O'Neal

Miles O'Neal

    Advanced Member

  • Members
  • PipPipPip
  • 144 posts

Posted 19 August 2019 - 08:48 PM

It depends on which version of ssl you are using. On RHEL7, ssh can use both ECDSA and ED25519. RHEL6 does not support either one. I have no idea what Windows or Mac supports. If you are using *nix, "man ssh" should tell you which algorithms are available; you'll obviously need to check on both ends.

#3 saudia

saudia

    Newbie

  • Members
  • Pip
  • 5 posts
  • LocationPittsburgh

Posted 20 August 2019 - 02:23 PM

Thanks.  I'm using an Ubuntu 16.04 server and it seems to have OpenSSL 1.0.2.  But, I've tried fingerprinting with every digest it supports and none of them match the fingerprint P4V gives me.

I set up a completely new test server and it does the same thing.  I also tested from both Ubuntu and Windows clients, and with P4V 2018.1 and 2019.1.  Same results.

So, then I connected to my server not with P4V but with the OpenSSL client itself, and the fingerprint I got that way did match.  So, P4V seems to be the problem.

#4 saudia

saudia

    Newbie

  • Members
  • Pip
  • 5 posts
  • LocationPittsburgh

Posted 24 August 2019 - 08:03 PM

Last reply, in as far as this is "solved" in the sense that I'm now confident there is no security risk, but not in the sense that we ever figured out how the fingerprint is generated.

On your Perforce server, you can use the command...

export P4SSLDIR=<path/to/certificate.txt>

p4d -Gf

...and it'll output the fingerprint you're looking for, which does match what I see being reported by P4V.  Still, no idea what hash/digest method is being used.




0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users