http://bugzilla.lysator.liu.se/show_bug.cgi?id=133
ceder(a)lysator.liu.se changed:
What |Removed |Added
----------------------------------------------------------------------------
Attachment #79 is|0 |1
obsolete| |
------- Additional Comments From ceder(a)lysator.liu.se 2005-03-09 11:05 -------
Created an attachment (id=80)
--> (http://bugzilla.lysator.liu.se/attachment.cgi?id=80&action=view)
Experimental TLS patch for lyskomd
Please attach patches as patches, so that they are easier to view. I've
extracted the lyskomd patch from attachment 79 and am now attaching only
that patch. Patch 79 also contains a patch for the elisp client.
I can see two problems with the patch:
- as the FIXME comment says, this patch blocks the entire server while
the TLS negotiation takes place. That is not acceptable.
- there is no test suite.
- a man in the middle could trick the client that the server does
not support TLS. The client would then presumably fall back to
using clear-text communication. I don't know if there is an easy
backwards-compatible fix. But the Protocol A documentation should
at least warn about this, and encourage client writers to take
measures against a denial-of-service attack. For instance, the
client could refuse to use clear-text against a server where it
in the past has been able to use TLS.
Nice-to-haves that the patch doesn't implement:
- A configuration option to require TLS. Make all calls except
start-tls return a new error, such as tls-required, unless TLS
is in use.
- Statistics on the number of clients that use TLS.
- Even more test cases.
What happens if the server requires a client certificate, but the
client fails to provide a valid certificate? Is the information
needed to diagnose such problems logged somewhere? I see no new
calls to kom_log in the patch.
------- You are receiving this mail because: -------
You are the QA contact for the bug, or are watching the QA contact.
http://bugzilla.lysator.liu.se/show_bug.cgi?id=133
------- Additional Comments From pont_lysbugzilla(a)soua.net 2005-03-09 10:12 -------
While SASL can provide data protection, I feel it's mainly focused on
authentication. TLS (RFC2246) can also provide both authentication services and
data protection, but I feel it's more focused on data protection.
I've provided experimental TLS-patches for lyskomd and the elisp client. Further
updates will likely be put at <URL:http://soua.net/lyskom_tls.tar.gz> (I'm not
certain whatever I'll attach new patches to the bug).
------- You are receiving this mail because: -------
You are the QA contact for the bug, or are watching the QA contact.
