jdev - 2019-10-03


  1. wurstsalat has left

  2. Daniel has joined

  3. lksjdflksjdf has left

  4. Kev has left

  5. Kev has joined

  6. Daniel has left

  7. Daniel has joined

  8. aj has joined

  9. Kev has left

  10. Kev has joined

  11. moparisthebest has left

  12. moparisthebest has joined

  13. Kev has left

  14. Kev has joined

  15. Daniel has left

  16. Daniel has joined

  17. Daniel has left

  18. bhaveshsgupta has left

  19. bhaveshsgupta has joined

  20. Kev has left

  21. Kev has joined

  22. Daniel has joined

  23. bhaveshsgupta has left

  24. Daniel has left

  25. bhaveshsgupta has joined

  26. Daniel has joined

  27. Kev has left

  28. Kev has joined

  29. Daniel has left

  30. rion has left

  31. rion has joined

  32. Daniel has joined

  33. Kev has left

  34. Kev has joined

  35. bhaveshsgupta has left

  36. Daniel has left

  37. bhaveshsgupta has joined

  38. Daniel has joined

  39. Kev has left

  40. Kev has joined

  41. bhaveshsgupta has left

  42. bhaveshsgupta has joined

  43. jrmu has left

  44. jrmu has joined

  45. Daniel has left

  46. Daniel has joined

  47. bhaveshsgupta has left

  48. bhaveshsgupta has joined

  49. aj has left

  50. Daniel has left

  51. Kev has left

  52. Daniel has joined

  53. bhaveshsgupta has left

  54. Daniel has left

  55. bhaveshsgupta has joined

  56. Daniel has joined

  57. Daniel has left

  58. Daniel has joined

  59. Daniel has left

  60. Daniel has joined

  61. bhaveshsgupta has left

  62. bhaveshsgupta has joined

  63. bhaveshsgupta has left

  64. bhaveshsgupta has joined

  65. bhaveshsgupta has left

  66. bhaveshsgupta has joined

  67. Zash has joined

  68. lovetox_ has joined

  69. bhaveshsgupta has left

  70. Kev has joined

  71. bhaveshsgupta has joined

  72. skyfar has joined

  73. bhaveshsgupta has left

  74. wurstsalat has joined

  75. bhaveshsgupta has joined

  76. Zash has left

  77. larma has left

  78. Daniel has left

  79. Daniel has joined

  80. Zash has joined

  81. larma has joined

  82. bhaveshsgupta has left

  83. Daniel has left

  84. bhaveshsgupta has joined

  85. aj has joined

  86. sonny has left

  87. sonny has joined

  88. bhaveshsgupta has left

  89. bhaveshsgupta has joined

  90. Daniel has joined

  91. marc0s has left

  92. marc0s has joined

  93. bhaveshsgupta has left

  94. debacle has joined

  95. bhaveshsgupta has joined

  96. bhaveshsgupta has left

  97. Daniel has left

  98. bhaveshsgupta has joined

  99. Daniel has joined

  100. bhaveshsgupta has left

  101. bhaveshsgupta has joined

  102. bhaveshsgupta has left

  103. lksjdflksjdf has joined

  104. bhaveshsgupta has joined

  105. bhaveshsgupta has left

  106. bhaveshsgupta has joined

  107. debacle has left

  108. bhaveshsgupta has left

  109. bhaveshsgupta has joined

  110. bhaveshsgupta has left

  111. bhaveshsgupta has joined

  112. sonny has left

  113. sonny has joined

  114. bhaveshsgupta has left

  115. bhaveshsgupta has joined

  116. bhaveshsgupta has left

  117. bhaveshsgupta has joined

  118. sonny has left

  119. sonny has joined

  120. bhaveshsgupta has left

  121. bhaveshsgupta has joined

  122. bhaveshsgupta has left

  123. Zash has left

  124. Zash has joined

  125. bhaveshsgupta has joined

  126. bhaveshsgupta has left

  127. bhaveshsgupta has joined

  128. bhaveshsgupta has left

  129. bhaveshsgupta has joined

  130. Zash has left

  131. Zash has joined

  132. lovetox_ has left

  133. bhaveshsgupta has left

  134. bhaveshsgupta has joined

  135. bhaveshsgupta has left

  136. bhaveshsgupta has joined

  137. skyfar has left

  138. sonny

    https://xmpp.org/rfcs/rfc6120.html#streams-error-conditions-see-other-host it's unclear to me, should I attempt direct TLS if the original intention was to connect using direct TLS?

  139. Wojtek has joined

  140. sonny

    direct TLS not being part of RFC 6120 I would say no but it says "the initiating entity MUST apply the same policies it would have applied to the original connection"

  141. MattJ

    I think "policies" means something different here

  142. sonny

    "(e.g., a policy requiring TLS)" doesn't help 😀

  143. sonny

    I mean if the user intentation was to use direct TLS wouldn't that qualify as a policy?

  144. aj has left

  145. bhaveshsgupta has left

  146. bhaveshsgupta has joined

  147. wurstsalat has left

  148. wurstsalat has joined

  149. bhaveshsgupta has left

  150. bhaveshsgupta has joined

  151. jrmu has left

  152. jrmu has joined

  153. jrmu has left

  154. jrmu has joined

  155. bhaveshsgupta has left

  156. bhaveshsgupta has joined

  157. bhaveshsgupta has left

  158. tom

    at least in email everybody uses TCP/587 STARTTLS now and refuses to connect if TLS isn't negotiated successfully

  159. tom

    TCP/467 is only for legacy reasons

  160. bhaveshsgupta has joined

  161. jonas’

    you wish

  162. Zash

    Oh submission/-s, not imap/-s. But it'll probably be 443 soon anyways 🙁

  163. tom

    it is if you try to shoehorn every last god damn thing into a browser

  164. Zash

    no, for real, everyone's singing high praise for jmap

  165. Zash

    which is json+https, like everything else

  166. Kev

    I'm not opposed to a j-xmpp for the last mile, I think it makes quite a lot of sense. Despite jabs about xmpp over json.

  167. jrmu has left

  168. jrmu has joined

  169. jrmu has left

  170. jrmu has joined

  171. Wojtek has left

  172. Wojtek has joined

  173. jrmu has left

  174. jrmu has joined

  175. debacle has joined

  176. lovetox has joined

  177. marc0s has left

  178. marc0s has joined

  179. qq has joined

  180. jrmu has left

  181. jrmu has joined

  182. qq has left

  183. asterix has joined

  184. asterix

    Hi Daniel, I'm ready to test conversation <-> Gajim FT

  185. Daniel

    asterix, ok

  186. Daniel

    can you add me on daniel@gultsch.de

  187. jrmu has left

  188. jrmu has joined

  189. jrmu has left

  190. jrmu has joined

  191. Wojtek has left

  192. Wojtek has joined

  193. jrmu has left

  194. rion has left

  195. rion has joined

  196. jrmu has joined

  197. Wojtek has left

  198. bhaveshsgupta has left

  199. bhaveshsgupta has joined

  200. Wojtek has joined

  201. lovetox has left

  202. jrmu has left

  203. jrmu has joined

  204. jrmu has left

  205. jrmu has joined

  206. jrmu has left

  207. jrmu has joined

  208. Egor Leontev has joined

  209. Egor Leontev has left

  210. asterix has left

  211. skyfar has joined

  212. jrmu has left

  213. moparisthebest

    tom: you missed https://tools.ietf.org/html/rfc8314 which brings smtps over TCP port 465 back

  214. tom

    huh

  215. moparisthebest

    Also IMAP/pop3/managesieve can go over any 443 or TLS port with their registered alpn extensions https://www.iana.org/assignments/tls-extensiontype-values/tls-extensiontype-values.xhtml#alpn-protocol-ids

  216. tom

    what happens when we stop using TLS like we did with SSL?

  217. moparisthebest

    Basically STARTLS is the deprecated way

  218. moparisthebest

    What do you mean?

  219. tom

    with cleartext init when TLS becomes deprecated we just deny STARTTLS and put in a STARTNGE (next generation encryption)

  220. tom

    Is STARTTLS any less secure than TLS?

  221. moparisthebest

    Quic ? :)

  222. moparisthebest

    It's complicated, but basically yes

  223. tom

    does anybody even use that besides google?

  224. moparisthebest

    Because it allows non encrypted and that's not acceptable today

  225. tom

    like the failure of webp

  226. moparisthebest

    Yes, everyone

  227. tom

    moparisthebest no, the server and or client can refuse further coms unless STARTLS is negotiated

  228. wurstsalat has left

  229. tom

    technically TLS is cleartext until KEX happens

  230. moparisthebest

    In practice though, it's impossible to try TLS and accidentally communicate in clear text

  231. tom

    I'm skeptical of QUIC and the security of stream ciphers

  232. moparisthebest

    Not true with STARTLS

  233. moparisthebest

    You better tell someone because like 50% of the web is already using it

  234. tom

    yeah

  235. tom

    and people adopted TLS session ticketing and got compromised too

  236. moparisthebest

    Curl, chrome, Firefox, cloudflare, Google, soon everyone else

  237. tom

    and then people adopted the complex HTTP/2 protocol too early before extensive in-practice testing could be finished and become vulnerable to RCEs

  238. moparisthebest

    I think it'll be great for xmpp too, no more stream management, just proper roaming

  239. tom

    I'm not saying it's not worh researching, I'm saying that calling STARTTLS or TCP/TLS 'deprecated' in favor of stream ciphers and UDP based transports is premature

  240. tom

    and I would like to see some practical examples of STARTTLS being less secure than TLS

  241. tom

    >‎moparisthebest‎: You better tell someone because like 50% of the web is already using it Not on my routers and DPI points

  242. moparisthebest

    There are plenty of examples of ISPs stripping starttls and bad clients etc still connecting

  243. moparisthebest

    I also don't know what you mean by stream ciphers, as I understand it quic *essentially* uses TLS 1.3

  244. moparisthebest

    Let me ask a different question instead, what advantage does Starttls have over direct TLS? I can't think of one

  245. tom

    if a client program connects in cleartext despite being configured not to that's a defect with the program not the protocol.

  246. tom

    yes, look at archived mailing lists from server operators of why we switched to a STARTTLS system in the first place?

  247. tom

    *.

  248. moparisthebest

    To save ports by allowing encrypted and unencrypted on the same port right?

  249. moparisthebest

    And now everyone agrees there should never be unencrypted, so again, what's the point?

  250. tom

    Stream ciphers are ciphers that can tolerate a dropped packets or other parts of the stream and not have to renegotiate

  251. tom

    this makes stopping stream tampering more difficult

  252. tom

    take AES for example

  253. tom

    normally you'd operate it in GCM mode

  254. tom

    not CTR mode

  255. tom

    we do this because there are all kinds side channels that open up when using it in stream mode

  256. tom

    like for example if you happen you run out of entropy, you expose your private key

  257. moparisthebest

    Has there been major problems with DTLS? Surely it's similar

  258. moparisthebest

    I'm not a cryptographer but I trust the IETF to get it right

  259. tom

    compound this with that popularity of virtualization, embedded computers, and Intel's backdoored hardware RNG blackbox

  260. tom

    it would be the first time a standards body had a malicious agenda https://en.wikipedia.org/wiki/Dual_EC_DRBG

  261. tom

    not saying it's impossible to have an unbreakable sidechannel free stream cipher, just saying it's really hard to get right and historically it's been done wrong a lot of times

  262. debacle has left

  263. moparisthebest

    that was NIST not IETF and many people knew from the start it was backdoored

  264. bhaveshsgupta has left