View Issue Details

IDProjectCategoryView StatusLast Update
0005003unrealircdpublic2017-10-09 17:26
ReporterHeXiLeDAssigned Tosyzop 
PrioritylowSeverityfeatureReproducibilityN/A
Status resolvedResolutionfixed 
PlatformLinuxOSAny:OS VersionLatest stable
Product Version4.0.13 
Target VersionFixed in Version4.0.16 
Summary0005003: ssl link certfp display in server links connections
DescriptionUpon connection of a link the only security information the admin/opers receive is something like:

(link) Secure link some.net -> other.net[@ip:port] established (TLSv1.2-ECDHE-RSA-AES256-GCM-SHA384-256bits)

The proposed feature is to have the link notice display the SHA256 certFP of the established link.

Simultaneously also displayed on /links (at least for opers/admins) and perhaps on /map
Additional InformationAlthough not of high importance, it would be nice to have the information displayed.

Example:
(link) Secure link some.net -> other.net[@ip:port] established (TLSv1.2-ECDHE-RSA-AES256-GCM-SHA384-256bits) using certificate fingerprint 2345fdw34r34d34r34r....

/links
remote.net fingerprint 2345fdw34r34d34r34r... local.net :1 the best net of all

Let me know which security concerns this may raise if made available to the regular user.
Tagscertfp, information, Secure Links, security
3rd party modules

Activities

syzop

2017-09-09 17:26

administrator   ~0019846

To answer your last question: showing the certificate fingerprint should be no security problem. After all, the fingerprint can be calculated from the certificate that is sent over the wire (unencrypted) during the SSL/TLS handshake.

Yes, I would be fine with showing the SSL fingerprint in the link message.
I presume this (also) has to do with the link issue you are having and having a hard time debugging it.
I was already considering the following (so not showing it always, but..see next):
If neither verify-certificate is yes nor password is sslclientcertfp, then show a notice like "consider adding verify-certificate yes or link::password <fingerprint>". Something like that.
I'm planning to add that to the release after this one (4.0.15).

As for exposing it to users.. I said it would be no security issue but.. I think it will not be useful. Users have no reason to see this. Also showing it in /MAP or /LINKS only for opers would require extra intra-server communication of this value, which is presently not available and.. even that aside, IMO it's not worth the effort, showing it on-link should be enough (if you are not already verifying).

HeXiLeD

2017-09-09 17:50

reporter   ~0019847

It is nice that you have planed to add such feature.|
The notice idea is great! :)

As for the /links /map idea. I understand. Would there be another way to make it simple to display on demand just to confirm the link certFP and match it with what is wanted ?

other than:
openssl s_client -connect hub.some.net:port < /dev/null 2>/dev/null | openssl x509 -fingerprint -noout -in /dev/stdin -sha512 #(sha256)


I also thought having the client certFP being displayed to opers when a client connects. Same principle.

Currently the oper only sees something like:
some.net.nat: *** Client connecting: nick (me@host) [ip.ip.ip.ip] {clients} [secure AES256-GCM-SHA384]

If the client uses a cert, it would be nice to see that on the same notice.

some.net.nat: *** Client connecting: nick (me@host) [ip.ip.ip.ip] {clients} [secure AES256-GCM-SHA384] using certificate fingerprint 2345fdw34r34d34r34r...

Also your idea of sending a notice could/should apply.

syzop

2017-10-09 17:26

administrator   ~0019908

Last edited: 2017-10-09 17:26

View 2 revisions

This is now more or less done as of 4.0.16. At least my idea.

If a user does not use any link verification then it will output a bunch of stuff. See https://www.unrealircd.org/docs/Link_verification

As you can see I don't go as far as you requested but I think this will suffice, since it (almost) only matters in such cases.

We use spkifp now rather than sslclientcertfp since the former will stay the same even for new certificates (as long as the keys are the same), this can be an advantage with Let's Encrypt (if you use the same keys and don't regenerate them every ~60 days like certbot does by default).

Issue History

Date Modified Username Field Change
2017-09-08 21:16 HeXiLeD New Issue
2017-09-08 21:16 HeXiLeD Tag Attached: certfp
2017-09-08 21:16 HeXiLeD Tag Attached: Secure Links
2017-09-08 21:16 HeXiLeD Tag Attached: security
2017-09-08 21:16 HeXiLeD Tag Attached: information
2017-09-09 17:19 syzop View Status private => public
2017-09-09 17:26 syzop Note Added: 0019846
2017-09-09 17:50 HeXiLeD Note Added: 0019847
2017-10-09 17:26 syzop Assigned To => syzop
2017-10-09 17:26 syzop Status new => resolved
2017-10-09 17:26 syzop Resolution open => fixed
2017-10-09 17:26 syzop Fixed in Version => 4.0.16
2017-10-09 17:26 syzop Note Added: 0019908
2017-10-09 17:26 syzop Note Edited: 0019908 View Revisions