An overview of secure communications with Jabber/XMPP IM technologies

1. Jabber security

2. Peter Saint-Andre

3. stpeter@jabber.org

5. https://stpeter.im/

6. secure communication

7. with Jabber

8. what is Jabber?

9. open XML technologies

10. real-time messaging

11. presence

12. multimedia negotiation

13. collaboration

14. and more

15. invented by Jeremie
Miller in 1998

16. in essence...

17. streaming XML

18. over long-lived
TCP connection

19. client-server
architecture

20. decentralized
network

21. inter-domain
messaging

22. like email

23. but really fast

24. with built-in presence

25. not just one
open-source project

26. multiple codebases

27. open-source and
commercial

28. interoperability via
XML wire protocol

29. core protocol
standardized @ IETF

30. Extensible

31. Messaging

32. and

33. Presence

34. Protocol

35. (XMPP)

36. RFCs 3920 + 3921

37. multiple
implementations

38. serious deployment

39. how many users?

40. we don’t know

41. decentralized
architecture

42. 100k+ servers

43. 50+ million IM users

44. not just IM

45. generic XML routing

46. lots of applications
beyond IM

47. continually defining
XMPP extensions

48. XMPP Standards
Foundation (XSF)

49. developer-driven
standards group

50. that’s great, but...

51. how secure is it?

52. what is security?

53. secure conversation
in real life...

54. a good friend
visits your home

55. you know and trust
each other

56. only the two of you

57. strangers can’t enter
your home

58. your home is not
bugged

59. conversation is not
recorded

60. what you say is private
and confidential

61. contrast that with
the Internet...

62. lots of potential attacks

63. man-in-the-middle

64. eavesdropping

65. unauthenticated users

66. address spoofing

67. weak identity

68. rogue servers

69. denial of service

70. directory harvesting

71. buffer overflows

72. spam

73. spim

74. spit

75. splogs

76. viruses

77. worms

78. trojan horses

79. malware

80. phishing

81. pharming

82. information leaks

83. inappropriate logging
and archiving

84. you get the picture

85. the Internet is a
dangerous place

86. how do we fight
these threats?

87. sorry, but...

88. Jabber is not a
perfect technology

89. not originally built
for high security

90. don’t require PGP keys
or X.509 certs

91. don’t require ubiquitous
encryption

92. tradeoffs between
security and usability

93. maybe that’s why we
have 50+ million users...

94. but privacy and security
are important

95. so what have we
done to help?

96. Jabber architecture...

98. similar to email

99. client connects to
server (TCP 5222)

100. (or connect via HTTP
binding over SSL)

101. client MUST
authenticate

102. originally: plaintext (!) or
hashed password

103. Simple Authentication &
Security Layer (SASL)

104. RFC 4422

105. many SASL mechanisms

106. PLAIN (OK over
encrypted connection)

107. DIGEST-MD5

108. EXTERNAL (with
X.509 certs)

109. GSSAPI
(a.k.a. Kerberos)

110. ANONYMOUS

111. etc.

112. all users are
authenticated

113. sender addresses not
merely asserted

114. server stamps
user ‘from’ address

115. Jabber IDs are
logical addresses

116. IP addresses
not exposed

117. Jabber ID looks like
an email address

118. romeo@montague.net

119. juliet@capulet.com

120. not limited to
US-ASCII characters

121. jiři@čechy.cz

122. πλατω@ἑλλας.gr

123. มฌำปจ@jabber.th

124. @jabber.jp

125. ∞@math.it

126. full Unicode opens
phishing attacks

127. STPETER@jabber.org
ᏚᎢᎵᎬᎢᎬᏒ@jabber.org

128. clients should use
“petnames”

129. store in buddy list [tm]
(a.k.a. “roster”)

130. server stores
your roster

131. server broadcasts
your presence

132. but only to subscribers
you have authorized

133. most traffic goes
through server

134. traffic is pure XML

135. servers reject
malformed XML

136. servers may validate
traffic against schemas

137. difficult to inject
binary objects

138. difficult to propagate
malware

139. break alliance between
viruses and spam

140. spam virtually unknown
on Jabber network

141. why?

142. hard to spoof
addresses

143. hard to send
inline binary

144. XHTML subset
(no scripts etc.)

145. user approval required
for file transfer

146. privacy lists to block
unwanted users

147. XMPP not immune
to spam

148. have spam-fighting tools
ready when it appears

149. challenge-response to
register an account

150. challenge-response to
communicate

151. spam reporting

152. working on more
anti-spam tools

153. server reputation
system?

154. anonymized IP address?
(groupchat spam)

155. spammers need to
overcome...

156. bandwidth limits

157. connection limits

158. other denial-of-service
prevention measures

159. distributed attack or
run a rogue server

160. not impossible

161. just harder than other
networks (got email?)

162. no rogue servers
(yet)

163. optional to federate
with other servers

164. many private
XMPP servers

165. public servers federate
as needed (TCP 5269)

166. DNS lookup to get
server IP address

167. only one hop
between servers

168. server identities
are validated

169. server dialback
(identity verification)

170. effectively prevents
server spoofing

171. receiving server checks
sending domain

172. no messages from
“service@paypal.com”

173. DNS poisoning
can invalidate

174. need something
stronger?

175. Transport Layer
Security (TLS)

176. RFC 4346

177. IETF “upgrade” to SSL

178. TLS + SASL EXTERNAL
with X.509 certs

179. strong authentication
of other servers

180. but only if certs are
not self-signed

181. $$$

182. real X.509 certs
are expensive

183. VeriSign, Thawte, etc.

184. a better way...

185. xmpp.net

186. intermediate CA for
XMPP network

187. free digital certificates
for XMPP server admins

188. (need to prove you
own the domain)

189. root CA: StartCom

190. ICA: XMPP Standards
Foundation

191. hopefully other CAs
in future

192. so channel encryption
is a no-brainer

193. man-in-the-middle
is much harder

194. “Mallory” is foiled

195. but what about
“Isaac” and “Justin”?

197. we can encrypt
the channels

198. but traffic is cleartext
within servers!

199. need end-to-end
encryption (“e2e”)

200. first try: OpenPGP
(XEP-0027)

201. great for geeks

202. but Aunt Tillie
doesn’t use PGP

203. second try: S/MIME
(RFC 3923)

204. great for geeks (and
some employees)

205. but Aunt Tillie
doesn’t use X.509

206. XML encryption and
digital signatures?

207. seems natural, but not
much interest (c14n?)

208. doesn’t provide perfect
forward secrecy

209. off-the-record
communication (OTR)?

210. great idea

211. opportunistic
encryption (à la SSH)

212. perfect forward secrecy

213. but encrypts only the
plaintext message body

214. we need to encrypt
the entire packet

215. why?

216. because XMPP is more
than just IM

217. protect IPs sent in
multimedia negotiation

218. protect shared XML
editing data

219. etc.

220. solution: encrypted
sessions

221. big set of
requirements...

222. packets are confidential

223. packet integrity

224. replay protection

225. key compromise does
not reveal past comms

226. don’t depend on public
key infrastructure

227. entities authenticated
to each other

228. 3rd parties cannot
identify entities

229. robustness against
attack (multiple hurdles)

230. upgradeability if bugs
are discovered

231. encryption of full
XMPP packets

232. implementable by
typical developer

233. usable by
typical user

234. how to address all
requirements?

235. just a dream?

236. bootstrap from
cleartext to encryption

237. in-band Diffie-Hellman
key exchange

238. translate “SIGMA”
approach to XMPP

239. similar to Internet Key
Exchange (IKE)

240. details in XSF XEPs
116, 188, 200

241. simplified profile
in XEP-0217

242. major priority for
2007-2008

243. support from NLnet
(thanks!)

244. pursuing full
security analysis

245. code bounties

246. GSoC project

247. Jabber security summit

248. more at
blog.xmpp.org

249. wide implementation
in next ~12 months

250. so how are we doing?

251. spam free

252. hard to spoof addresses

253. pure XML discourages
binary malware

254. DoS attacks possible
but not easy

255. widespread channel
encryption

256. working hard on
end-to-end encryption

257. widely deployed in high-
security environments

258. Wall Street
investment banks

259. U.S. military

260. MIT and other
universities

261. many public servers
since 1999

262. no major security
breaches

263. can’t be complacent

264. always more to do

265. security is a never-
ending process

266. analysis and hacking
are encouraged

267. if it breaks,
we’ll fix it

268. security@xmpp.org

269. join the conversation

270. let’s build
a more secure Internet