View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0005003 | unreal | ircd | public | 2017-09-08 21:16 | 2017-10-09 17:26 |
| Reporter | HeXiLeD | Assigned To | syzop | ||
| Priority | low | Severity | feature | Reproducibility | N/A |
| Status | resolved | Resolution | fixed | ||
| Platform | Linux | OS | Any: | OS Version | Latest stable |
| Product Version | 4.0.13 | ||||
| Fixed in Version | 4.0.16 | ||||
| Summary | 0005003: ssl link certfp display in server links connections | ||||
| Description | Upon 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 Information | Although 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. | ||||
| Tags | certfp, information, Secure Links, security | ||||
| 3rd party modules | |||||
|
|
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). |
|
|
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. |
|
|
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). |
| 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 |
