TLS Authentication on Freenode and OFTCFeeding the Cloud
<a href="https://creativecommons.org/licenses/by-sa/4.0/">Creative Commons Attribution-ShareAlike 4.0 International License</a>
https://feeding.cloud.geek.nz/posts/tls_authentication_freenode_and_oftc/Feeding the Cloudikiwiki2018-10-08T02:40:38Zproblems with certificate-based TLS authentication for IRChttps://feeding.cloud.geek.nz/posts/tls_authentication_freenode_and_oftc/comment_1_c11c1c8d07ec6290bdc3fe0a5c305de2/Daniel Kahn Gillmor2017-09-11T16:26:33Z2017-09-11T15:13:56Z
<p>I used to use this approach myself, but i stopped using it a few years
ago, for two reasons:</p>
<ul>
<li><p>certificate expiration -- when my registered certificate expires, i
still need to update the server with my new certificate. to do that,
i need my password. so my password still works, and i still have to
retain it and send it to (what i hope is the correct) nickserv
service at each cert renewal time. so this doesn't actually remove
either my needing to remember/retain/record a password, and it
doesn't make my remembered/recorded password less powerful.</p></li>
<li><p>client certificate leakage -- in TLS versions 1.2 and earlier (all
deployed versions of TLS), the client certificate is exchanged in the
clear, during the handshake. (TLS 1.3 will fix this, but it is not yet fully standardized or in deployed production). This means that client cert
authentication actually leaks your identity to any passive network
observer, whereas password-based authentication to nickserv does not.</p></li>
</ul>
<p>This pains me, because i generally <em>strongly</em> prefer pubkey-based
authentication over password-based authentication. But in this case, i
think it's not enough of a win overall to make the transition.</p>
<p>What do you think about these tradeoffs? Are there mitigating factors that i should know about that makes them less troubling?</p>
Followup: https://feeding.cloud.geek.nz/posts/tls_authentication_freenode_and_oftc/comment_2_dac77c215afa19d55048c700d8fdd922/Daniel Kahn Gillmor2017-09-14T00:32:52Z2017-09-13T21:57:33Z
<p>Thanks to this discussion, i just opened a <a href="https://github.com/irssi/irssi/issues/756">bug report on irssi</a> to try to resolve the second issue above by sending client certificates in a renegotiated handshake.</p>
<p>I've tested irssi, and it definitely does leak the user's public certificate to a passive network monitor.</p>
<p>I haven't tested ZNC yet -- If someone wanted to open a similar report for ZNC, i'd appreciate it.</p>
<p>If you want to test to see whether it's dumping traffic, you can do this with tshark:</p>
<pre><code>tshark -O ssl -Y 'ssl.handshake.certificates_length > 1 && ssl.record.content_type == 22' -o http.ssl.port:6697 port 6697
</code></pre>
<p>I don't have a patch to propose for either irssi or ZNC yet, and don't have much time to work on it myself. I'd be happy to see that happen, because it would remove one of the major downsides to using certificates for IRC.</p>
tls authentication freenode and oftchttps://feeding.cloud.geek.nz/posts/tls_authentication_freenode_and_oftc/comment_3_ff61fc9636d7df82c721a08c8be0b9a7/austere2018-10-08T02:40:38Z2018-10-08T00:55:14Z
Has the irssi certificate leakage been fixed yet?