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


  63. fippo

    take that as comparison :-)

  64. Simon


  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


  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


  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


  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


  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


  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


  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


  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


  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


  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


  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. ([]: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


  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


  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