Secure Communications with Jabber

5,227
-1

Published on

An overview of secure communications with Jabber/XMPP IM technologies

Published in: Technology
0 Comments
4 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
5,227
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
124
Comments
0
Likes
4
Embeds 0
No embeds

No notes for slide

Secure Communications with Jabber

  1. 1. Jabber security
  2. 2. Peter Saint-Andre
  3. 3. stpeter@jabber.org
  4. 4. https://stpeter.im/
  5. 5. secure communication
  6. 6. with Jabber
  7. 7. what is Jabber?
  8. 8. open XML technologies
  9. 9. real-time messaging
  10. 10. presence
  11. 11. multimedia negotiation
  12. 12. collaboration
  13. 13. and more
  14. 14. invented by Jeremie Miller in 1998
  15. 15. in essence...
  16. 16. streaming XML
  17. 17. over long-lived TCP connection
  18. 18. client-server architecture
  19. 19. decentralized network
  20. 20. inter-domain messaging
  21. 21. like email
  22. 22. but really fast
  23. 23. with built-in presence
  24. 24. not just one open-source project
  25. 25. multiple codebases
  26. 26. open-source and commercial
  27. 27. interoperability via XML wire protocol
  28. 28. core protocol standardized @ IETF
  29. 29. Extensible
  30. 30. Messaging
  31. 31. and
  32. 32. Presence
  33. 33. Protocol
  34. 34. (XMPP)
  35. 35. RFCs 3920 + 3921
  36. 36. multiple implementations
  37. 37. serious deployment
  38. 38. how many users?
  39. 39. we don’t know
  40. 40. decentralized architecture
  41. 41. 100k+ servers
  42. 42. 50+ million IM users
  43. 43. not just IM
  44. 44. generic XML routing
  45. 45. lots of applications beyond IM
  46. 46. continually defining XMPP extensions
  47. 47. XMPP Standards Foundation (XSF)
  48. 48. developer-driven standards group
  49. 49. that’s great, but...
  50. 50. how secure is it?
  51. 51. what is security?
  52. 52. secure conversation in real life...
  53. 53. a good friend visits your home
  54. 54. you know and trust each other
  55. 55. only the two of you
  56. 56. strangers can’t enter your home
  57. 57. your home is not bugged
  58. 58. conversation is not recorded
  59. 59. what you say is private and confidential
  60. 60. contrast that with the Internet...
  61. 61. lots of potential attacks
  62. 62. man-in-the-middle
  63. 63. eavesdropping
  64. 64. unauthenticated users
  65. 65. address spoofing
  66. 66. weak identity
  67. 67. rogue servers
  68. 68. denial of service
  69. 69. directory harvesting
  70. 70. buffer overflows
  71. 71. spam
  72. 72. spim
  73. 73. spit
  74. 74. splogs
  75. 75. viruses
  76. 76. worms
  77. 77. trojan horses
  78. 78. malware
  79. 79. phishing
  80. 80. pharming
  81. 81. information leaks
  82. 82. inappropriate logging and archiving
  83. 83. you get the picture
  84. 84. the Internet is a dangerous place
  85. 85. how do we fight these threats?
  86. 86. sorry, but...
  87. 87. Jabber is not a perfect technology
  88. 88. not originally built for high security
  89. 89. don’t require PGP keys or X.509 certs
  90. 90. don’t require ubiquitous encryption
  91. 91. tradeoffs between security and usability
  92. 92. maybe that’s why we have 50+ million users...
  93. 93. but privacy and security are important
  94. 94. so what have we done to help?
  95. 95. Jabber architecture...
  96. 96. similar to email
  97. 97. client connects to server (TCP 5222)
  98. 98. (or connect via HTTP binding over SSL)
  99. 99. client MUST authenticate
  100. 100. originally: plaintext (!) or hashed password
  101. 101. Simple Authentication & Security Layer (SASL)
  102. 102. RFC 4422
  103. 103. many SASL mechanisms
  104. 104. PLAIN (OK over encrypted connection)
  105. 105. DIGEST-MD5
  106. 106. EXTERNAL (with X.509 certs)
  107. 107. GSSAPI (a.k.a. Kerberos)
  108. 108. ANONYMOUS
  109. 109. etc.
  110. 110. all users are authenticated
  111. 111. sender addresses not merely asserted
  112. 112. server stamps user ‘from’ address
  113. 113. Jabber IDs are logical addresses
  114. 114. IP addresses not exposed
  115. 115. Jabber ID looks like an email address
  116. 116. romeo@montague.net
  117. 117. juliet@capulet.com
  118. 118. not limited to US-ASCII characters
  119. 119. jiři@čechy.cz
  120. 120. πλατω@ἑλλας.gr
  121. 121. มฌำปจ@jabber.th
  122. 122. @jabber.jp
  123. 123. ∞@math.it
  124. 124. full Unicode opens phishing attacks
  125. 125. STPETER@jabber.org ᏚᎢᎵᎬᎢᎬᏒ@jabber.org
  126. 126. clients should use “petnames”
  127. 127. store in buddy list [tm] (a.k.a. “roster”)
  128. 128. server stores your roster
  129. 129. server broadcasts your presence
  130. 130. but only to subscribers you have authorized
  131. 131. most traffic goes through server
  132. 132. traffic is pure XML
  133. 133. servers reject malformed XML
  134. 134. servers may validate traffic against schemas
  135. 135. difficult to inject binary objects
  136. 136. difficult to propagate malware
  137. 137. break alliance between viruses and spam
  138. 138. spam virtually unknown on Jabber network
  139. 139. why?
  140. 140. hard to spoof addresses
  141. 141. hard to send inline binary
  142. 142. XHTML subset (no scripts etc.)
  143. 143. user approval required for file transfer
  144. 144. privacy lists to block unwanted users
  145. 145. XMPP not immune to spam
  146. 146. have spam-fighting tools ready when it appears
  147. 147. challenge-response to register an account
  148. 148. challenge-response to communicate
  149. 149. spam reporting
  150. 150. working on more anti-spam tools
  151. 151. server reputation system?
  152. 152. anonymized IP address? (groupchat spam)
  153. 153. spammers need to overcome...
  154. 154. bandwidth limits
  155. 155. connection limits
  156. 156. other denial-of-service prevention measures
  157. 157. distributed attack or run a rogue server
  158. 158. not impossible
  159. 159. just harder than other networks (got email?)
  160. 160. no rogue servers (yet)
  161. 161. optional to federate with other servers
  162. 162. many private XMPP servers
  163. 163. public servers federate as needed (TCP 5269)
  164. 164. DNS lookup to get server IP address
  165. 165. only one hop between servers
  166. 166. server identities are validated
  167. 167. server dialback (identity verification)
  168. 168. effectively prevents server spoofing
  169. 169. receiving server checks sending domain
  170. 170. no messages from “service@paypal.com”
  171. 171. DNS poisoning can invalidate
  172. 172. need something stronger?
  173. 173. Transport Layer Security (TLS)
  174. 174. RFC 4346
  175. 175. IETF “upgrade” to SSL
  176. 176. TLS + SASL EXTERNAL with X.509 certs
  177. 177. strong authentication of other servers
  178. 178. but only if certs are not self-signed
  179. 179. $$$
  180. 180. real X.509 certs are expensive
  181. 181. VeriSign, Thawte, etc.
  182. 182. a better way...
  183. 183. xmpp.net
  184. 184. intermediate CA for XMPP network
  185. 185. free digital certificates for XMPP server admins
  186. 186. (need to prove you own the domain)
  187. 187. root CA: StartCom
  188. 188. ICA: XMPP Standards Foundation
  189. 189. hopefully other CAs in future
  190. 190. so channel encryption is a no-brainer
  191. 191. man-in-the-middle is much harder
  192. 192. “Mallory” is foiled
  193. 193. but what about “Isaac” and “Justin”?
  194. 194. we can encrypt the channels
  195. 195. but traffic is cleartext within servers!
  196. 196. need end-to-end encryption (“e2e”)
  197. 197. first try: OpenPGP (XEP-0027)
  198. 198. great for geeks
  199. 199. but Aunt Tillie doesn’t use PGP
  200. 200. second try: S/MIME (RFC 3923)
  201. 201. great for geeks (and some employees)
  202. 202. but Aunt Tillie doesn’t use X.509
  203. 203. XML encryption and digital signatures?
  204. 204. seems natural, but not much interest (c14n?)
  205. 205. doesn’t provide perfect forward secrecy
  206. 206. off-the-record communication (OTR)?
  207. 207. great idea
  208. 208. opportunistic encryption (à la SSH)
  209. 209. perfect forward secrecy
  210. 210. but encrypts only the plaintext message body
  211. 211. we need to encrypt the entire packet
  212. 212. why?
  213. 213. because XMPP is more than just IM
  214. 214. protect IPs sent in multimedia negotiation
  215. 215. protect shared XML editing data
  216. 216. etc.
  217. 217. solution: encrypted sessions
  218. 218. big set of requirements...
  219. 219. packets are confidential
  220. 220. packet integrity
  221. 221. replay protection
  222. 222. key compromise does not reveal past comms
  223. 223. don’t depend on public key infrastructure
  224. 224. entities authenticated to each other
  225. 225. 3rd parties cannot identify entities
  226. 226. robustness against attack (multiple hurdles)
  227. 227. upgradeability if bugs are discovered
  228. 228. encryption of full XMPP packets
  229. 229. implementable by typical developer
  230. 230. usable by typical user
  231. 231. how to address all requirements?
  232. 232. just a dream?
  233. 233. bootstrap from cleartext to encryption
  234. 234. in-band Diffie-Hellman key exchange
  235. 235. translate “SIGMA” approach to XMPP
  236. 236. similar to Internet Key Exchange (IKE)
  237. 237. details in XSF XEPs 116, 188, 200
  238. 238. simplified profile in XEP-0217
  239. 239. major priority for 2007-2008
  240. 240. support from NLnet (thanks!)
  241. 241. pursuing full security analysis
  242. 242. code bounties
  243. 243. GSoC project
  244. 244. Jabber security summit
  245. 245. more at blog.xmpp.org
  246. 246. wide implementation in next ~12 months
  247. 247. so how are we doing?
  248. 248. spam free
  249. 249. hard to spoof addresses
  250. 250. pure XML discourages binary malware
  251. 251. DoS attacks possible but not easy
  252. 252. widespread channel encryption
  253. 253. working hard on end-to-end encryption
  254. 254. widely deployed in high- security environments
  255. 255. Wall Street investment banks
  256. 256. U.S. military
  257. 257. MIT and other universities
  258. 258. many public servers since 1999
  259. 259. no major security breaches
  260. 260. can’t be complacent
  261. 261. always more to do
  262. 262. security is a never- ending process
  263. 263. analysis and hacking are encouraged
  264. 264. if it breaks, we’ll fix it
  265. 265. security@xmpp.org
  266. 266. join the conversation
  267. 267. let’s build a more secure Internet
  1. A particular slide catching your eye?

    Clipping is a handy way to collect important slides you want to go back to later.

×