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