XSF Discussion - 2013-12-15


  1. Lance has joined
  2. Lance has left
  3. stpeter has joined
  4. stpeter has left
  5. Lance has joined
  6. Simon has joined
  7. Lance has joined
  8. stpeter has joined
  9. stpeter has left
  10. Simon has left
  11. Lance has joined
  12. tato has joined
  13. Lance has left
  14. tato has left
  15. tato has joined
  16. Lance has joined
  17. Lance has left
  18. Lance has joined
  19. Lance has left
  20. waqas has left
  21. fippo has joined
  22. Lance has joined
  23. Simon has joined
  24. Kev has left
  25. Simon has left
  26. Kev has joined
  27. Simon has joined
  28. Alex has joined
  29. Lance has joined
  30. Simon has joined
  31. fsteinel has joined
  32. tato has left
  33. fsteinel has left
  34. Simon has left
  35. Simon has joined
  36. fippo has joined
  37. Simon has left
  38. kevin. has joined
  39. Simon has joined
  40. kevin. back, after a long time. 8)
  41. Simon Where were you Kevin?
  42. Simon oh not the Kev. There is more than one.
  43. kevin. There are two.
  44. Kev There's only one me, though.
  45. Simon Kev, how's Doomsong's cert fixing going?
  46. Simon Or are you gunning for DNSSEC being widespread enough that you can drop it? :)
  47. kevin. yeah, only one kev smith. and i'm not that
  48. Kev Simon: I need to sort this out, thanks for reminding me
  49. Kev puts into todo
  50. Kev Conveniently, I'm in the middle of capturing todos at the moment :)
  51. Simon buddycloud.com/org just completed readiness for Jan 4th.
  52. tato has joined
  53. kevin. has left
  54. fippo simon: post to operators@ instead
  55. fippo 91.5% of servers allowing starttls is good.
  56. Simon fippo: will do in the future
  57. Simon MITM says "I'd rather not startTLS". So still MITM-able.
  58. fippo we're not going to stop being MITM-able in january.
  59. Simon agreed: 4th Jan will help us understand what breaks.
  60. Simon like the ipv6 days.
  61. Simon My point is that we have a benchmark and can see if we're increasing.
  62. fippo http://mail.jabber.org/pipermail/standards/2007-July/016086.html
  63. fippo take that as comparison :-)
  64. Simon shocking…
  65. Simon makes the http cert world look pristine.
  66. tato has left
  67. fippo sure. nobody seemed to care back then
  68. fippo and your 8.5% figure is misleading. tls will typically be used when it's offered, so it's likely used on 91.5% of the connections
  69. fippo and 51% are most likely non-mitmable
  70. fippo which is not bad
  71. Simon how many of that 8.5% are also doing certificate auth?
  72. fippo I don't think many people are requiring certificate auth
  73. Simon so still mitm-able then.
  74. fippo sure.
  75. fippo but manifesto is not about changing that
  76. Simon I'm going to log a check for that on https://bitbucket.org/xnyhps/xmppoke/issues?status=new&status=open
  77. fippo there is no safe way to tell if a remote server enforces your cert
  78. Simon https://bitbucket.org/xnyhps/xmppoke/issue/12/test-for-invalid-certificates-certificate
  79. stpeter has joined
  80. stpeter has left
  81. Simon has joined
  82. Simon has left
  83. Simon has joined
  84. fippo simon: I like that ;-)
  85. fippo kev: just pushed updated jingle-grouping/jingle-sources :-)
  86. Kev fippo: There is for C2S, mind.
  87. Simon kev: cert checking or Jingle?
  88. Kev A way to check that the other end's connection to you isn't MITMable.
  89. Simon yeah - imho this is important. (ref: one of DWD's speeches on certs and authenticity etc etc)
  90. Kev Simon: So, do you use -PLUS? :)
  91. Kev fippo: So, ready for a revote on Wednesday, then?
  92. Simon g+?
  93. fippo kev: yes please
  94. Kev Simon: No, SCRAM-SHA-1-PLUS.
  95. Kev That's the only way the server can check that the client's not going to be MITMd.
  96. Simon kev - yes.
  97. Kev And even that's not perfect.
  98. Simon I'm more concerned about s2s in this case.
  99. fippo kev: but that doesn't allow you to tell if the remote server is using your cert to auth either (actually, why would it request scram from you?)
  100. Kev fippo: -PLUS doesn't help with S2S, but it helps greatly with C2S.
  101. Kev But only if a client doesn't allow a downgrade to PLAIN.
  102. Kev Which ~=everyone does.
  103. MattJ Kev, and Swift? :)
  104. Kev Swift doesn't do mech pinning.
  105. MattJ "Yet"?
  106. MattJ I've been considering taking a client and making it "totally secure", and re-releasing it
  107. Kev Yet, indeed.
  108. MattJ Swift is obviously a good candidate
  109. Kev There are a number of sensible things to do there, and motivation to do them.
  110. MattJ I'm talking about removing support for anything but TLS 1.2, SCRAM-PLUS, etc.
  111. MattJ No certificate validation bypass
  112. Kev This doesn't sound like fun
  113. MattJ For whom? :)
  114. Kev Well - what's the motivation?
  115. Kev Protection against downgrades is very sensible, and doesn't stop users using the client.
  116. Kev But stripping out widely used things because they're not deemed to be maximally secure doesn't seem altogether helpful.
  117. waqas has joined
  118. Kev How many TLS 1.1 vulnerabilities are we seeing?
  119. MattJ Just because we aren't seeing them doesn't mean they aren't there
  120. Kev And there's no point forking Swift for this, BTW. We have a mechanism for enforcing policies by sysadmins.
  121. MattJ Everyone should realise that by now :)
  122. MattJ Kev, then I'd repackage it at least
  123. Kev Why?
  124. MattJ and you probably wouldn't want me calling it just "Swift" at that point
  125. MattJ then how do I configure it?
  126. MattJ brb
  127. Kev Linux: Install an extra make-Swift-paranoid package, Windows you can have such a checkbox in the installer, and I'm sure something can be worked out for Mac.
  128. Simon the node-XMPP guys are doing some good work to move their code to nicely support TLSv.1.2
  129. MattJ Kev, are there docs on this?
  130. Kev MattJ: No.
  131. Kev But happy to chat about it over <- there in swift@.
  132. MattJ Ok, when I have some time :)
  133. Simon has left
  134. Simon has joined
  135. Simon has left
  136. Simon has joined
  137. waqas has left
  138. waqas has joined
  139. Lance has joined
  140. tato has joined
  141. Alex has left
  142. Alex has joined
  143. emcho has left
  144. emcho has joined
  145. Lance has joined
  146. Lance has joined
  147. Simon oops - didn't mean to dredge up the digest beast in members@
  148. MattJ Too late, it is awake
  149. Simon Hopefully it's died out by the time I'm back (10th Jan)
  150. Kev I'm not sure bringing up requirements for TLS is necessarily staying on-message at the moment.
  151. Kev While there's simultaneously the opportunistic TLS days happening.
  152. MattJ For folks not in the Prosody room, I'm currently working on a mod_manifesto
  153. MattJ https://matthewwild.co.uk/uploads/mod_manifesto_1.png
  154. Simon That's really nice MattJ
  155. Simon In terms of the text - it might put it in context to describe the problem/why at the start.
  156. MattJ It's configurable by the admin, but this is the default message - I'm happy to take suggested amendments
  157. MattJ I don't want it t o get too verbose
  158. Simon yes.
  159. MattJ I should clarify that the list is completely automated - it is only sent to users who have contacts on unencrypted s2s links
  160. Simon I'd expect nothing less from the Prosody team.
  161. MattJ I'm going to implement the actual test days into the module too if I can - overriding the config to allow only encrypted connections for the 24h period
  162. MattJ which also means I'm aiming for UTC...
  163. MattJ unless people think that's a bad idea
  164. Simon TZ of least confusion.
  165. waqas MattJ: Do we have good error responses on lack of TLS?
  166. MattJ waqas, as good as could be expected
  167. waqas Both for local users, and for remote
  168. MattJ I'm thinking of having mod_manifesto rewrite them for the test day though
  169. MattJ waqas, yes, the error message says that the delivery failure was due to lack of encryption
  170. waqas The folks we probably want to make the most aware of this are the people on servers without good encryption
  171. waqas Not the local users, who are already on a good server
  172. MattJ Yep
  173. MattJ I considered spamming them, but... ;)
  174. Simon is impressed with Prosody's preparedness.
  175. Simon I expect all users will get a notification until jabber.org gets ready.
  176. Kev jabber.org /is/ ready, is it not?
  177. Kev In that the only thing that's needed to be ready is to have a cert.
  178. fippo kev: i think it would be good to have jabber.org reject non-tls connection
  179. Simon https://xmpp.net/result.php?domain=jabber.org&type=server
  180. fippo otherwise "but it works with jabber.org!!!!" is true
  181. Simon and fix it's cipherlist
  182. Kev Simon: Nothing on that page looks incompatible with servers participating in the event.
  183. Kev To me.
  184. Kev fippo: Yes, I expect we will.
  185. fippo i wonder why jabber.orgs pubkey score is sooo low
  186. Kev Because it bundles the root (Which is a pretty sensible thing to do)?
  187. MattJ Why is it a sensible thing to do?
  188. Kev MattJ: Because if you're going to do leap of faith, having the root gives you a better basis for future upgrades.
  189. Simon Presumably the root should come from outside the connections / OS /Browser.
  190. Simon intermediate should be included though
  191. Simon also the cert is for conference.jabber.org.
  192. Kev The cname is c.j.o, which isn't the same thing.
  193. Kev It has the right SANs in it as far as I know.
  194. fippo there is a bug for xmpp.net that it should show SANs
  195. fippo i even have code for it but can't get the tool itself to work for me
  196. Simon fippo: this one https://bitbucket.org/xnyhps/xmppoke/issue/3/show-certificate-subjectalternativenames ?
  197. fippo simon: yeah
  198. Simon If anyone is looking for a well considered, peer reviewed ciphersuite, Mozilla Opsec have a good writeup: https://wiki.mozilla.org/Security/Server_Side_TLS#Recommended_Ciphersuite
  199. simon has joined
  200. Simon fippo: solved you cert problem a different way https://xmpp.net/result.php?domain=estos.de&type=server ?
  201. tato has left
  202. fippo simon: huh? it has always shown as valid
  203. fippo it just doesn't show why this one is valid :-)
  204. Simon reread your xmpppoke issue. Makes sense now.
  205. tato has joined
  206. tato has left
  207. simon has left
  208. Lance has joined
  209. tato has joined
  210. Simon interestingly buddycloud.com refuses to speak to jabber.org too with the current cert.
  211. Simon Dec 15 21:34:43 s2sout22aafc0 info Beginning new connection attempt to jabber.org. ([208.68.163.218]:5269) Dec 15 21:34:44 mod_s2s warn Forbidding insecure connection to/from jabber.org. Dec 15 21:34:44 s2sout22aafc0 info outgoing s2s stream buddycloud.com->jabber.org. closed: stream closed Dec 15 21:34:44 s2sout22aafc0 info sending error replies for 2 queued stanzas because of failed outgoing connection to jabber.org.
  212. Simon s2s_secure_auth = true s2s_require_encryption = true
  213. tato has left
  214. MattJ I don't know why that would be
  215. tato has joined
  216. tato has left
  217. tato has joined
  218. tato has left
  219. SouL has left
  220. tato has joined
  221. MattJ Haaa
  222. tato has left
  223. MattJ I know what the issue is, there is a '.' at the end of the hostname
  224. Simon the cert or the contact?
  225. MattJ Someone is trying to send something to "jabber.org."
  226. Simon right
  227. MattJ I vaguely recall something about this in the RFC
  228. Zash has joined
  229. MattJ Yes, it's in 6122
  230. MattJ It must be stripped, but it doesn't say where
  231. tato has joined
  232. tato has left
  233. MattJ well, it says: "this character MUST be stripped from the domainpart before the JID of which it is a part is used for the purpose of routing an XML stanza, comparing against another JID, or constructing an [XMPP‑URI]. "
  234. SouL has joined
  235. MattJ So it's a client bug for allowing it and a server bug for not stripping it either I suppose
  236. Simon server bug for storing it in the roster table too?
  237. MattJ Not necessarily storing it
  238. MattJ I don't know if roster entries must be in normalized form
  239. Alex has left
  240. Zash Let's blame jabber.org for answering to "jabber.org."
  241. Zash Prosody says host-unknown
  242. fsteinel has joined
  243. Simon has left
  244. tato has joined
  245. fsteinel has left
  246. Simon has joined
  247. Simon has left
  248. Lance has joined