freenode/#shirakumo - IRC Chatlog
Search
13:31:33
Shinmera
Jul 21 15:18:58 fermion sbcl[24849]: 2017-07-21 15:18:58 [TRACE] <LICHAT.SERVER.TCP>: #<CONNECTION Colleen/0>: Waiting for message...
13:31:35
Shinmera
Jul 21 15:18:58 fermion sbcl[24849]: 2017-07-21 15:18:58 [TRACE] <LICHAT.SERVER.TCP>: #<CONNECTION Colleen/0>: Input ready.
13:31:37
Shinmera
Jul 21 15:18:58 fermion sbcl[24849]: 2017-07-21 15:18:58 [TRACE] <LICHAT.SERVER.TCP>: #<CONNECTION Colleen/0>: Waiting for message...
13:31:39
Shinmera
Jul 21 15:18:58 fermion sbcl[24849]: 2017-07-21 15:18:58 [TRACE] <LICHAT.SERVER.TCP>: #<CONNECTION Colleen/0>: Input ready.
13:31:41
Shinmera
Jul 21 15:29:51 fermion sbcl[24849]: 2017-07-21 15:29:51 [TRACE] <LICHAT.SERVER.TCP>: #<SERVER TyNET>: Sending #<LICHAT-PROTOCOL:CONNECTION-UNSTABLE :FROM TyNET :ID 2952017866 :TEXT "Ping idle-timeout of 120 seconds reached."> to #<CONNECTION Colleen/0>
13:33:08
Shinmera
Though that doesn't make sense... since then it wouldn't notice the unstable thing
19:20:53
mood
Shinmera: I'd generally think "opportunistic encryption", like STARTTLS, is a bit of a minefield and thus undesirable. But I don't know particularly much about this stuff
19:52:37
Shinmera
Well, STRIPTLS just means you don't announce that the server supports STARTTLS, thus forcing the client to downgrade
19:53:27
Shinmera
The problem here lying in the backwards-compatibility of allowing there to be no TLS
19:55:20
mood
But then what's the benefit of STARTTLS over just negotiating a secure connection in the first place?
19:56:30
Shinmera
As usual with network protocols, there's going to be a lot more clients than there ever will be servers. So I deem it fine to put more burden on the server writer than the client writer.
19:59:33
mood
I think the sanest option would be to just require encryption at all times, though that makes implementation harder
20:34:56
Shinmera
Aight. If you ever have time I'd appreciate it if you could. You might notice something missing/wrong that I've overlooked.