On 15 Apr 2016, at 01:00, Ian Batten <xxx> wrote:
If anyone is keen enough to be running their own VPN server for Apple clients
More detailed examination with coffee in my hand (hey, I teach two lectures on IPSec and IKE, so this is _real_ _work_) reveals that on the down-low, Apple have re-written the entire opening phase of their VPN software and released it on two platforms over the past couple of weeks.
Historically, the Apple L2TP-over-IPSec implementation was as brittle as thin glass. The recommended deployment was talking to an Apple “Server” on OSX, but if you wanted to roll your own, it was very difficult to end up with an IKE configuration which would work with the Apple clients and also work with anything else. In essence, you had to configure the server with exactly the algorithms used at each phase by Apple, and none others: if you so much as mentioned an algorithm the clients didn’t support, the whole thing collapsed. I don’t have anything other than Apple kit in my mobile VPN estate so this didn’t matter to me, but I gather from former colleagues that using the Apple VPN client and the Microsoft VPN client into the same server is the best tool in your Cisco’s salesman’s box to convince you to just buy the end-to-end Cisco solution. Which Apple kind-of admitted by shipping the Cisco VPN client, branded, as a standard part of iOS (I think I’m right in saying that it’s the only piece of iOS as installed on a new device which has anyone else’s branding on).
The new stuff is completely different. You can turn on all the algorithms you like, and the Apple clients (a) in main mode, negotiate a sensible mutual combination of algorithms and use those for the rest of the exchange and (b) more impressively, in aggressive mode (where the two ends need to know in advance what algorithms are in use, as there’s no “what has and encryption do you fancy?” phase) it steps through a sequence of proposals to try to find one that works: that’s not fast, but at least it works. So you can turn on the offer of algorithms that Apple don’t support yet (large DH groups, EC crypto, SHA512, that sort of thing) and leave them there waiting for the clients to catch up, and for use by more capable clients.
There’s some other changes which aren’t as easy to analyse. The negotiation of PFS has definitely changed: it used to be that if you asked for it on the server, the client dropped the connection, now you can have it enabled with a group selected. But it’s not obvious whether it’s actually respected: since you can ask for crazy groups (6144 bits) or for things that don’t appear to be supported anywhere else in the Apple client (EC) and it still “works”, the implication is that the client is just doing a better (or worse, depending on your view) job of negotiation and is not using PFS even though it’s offered. I’m not sure how to check this. The packet sequence is the same, and although the contents are different they are encrypted: I’d need to find a way to get hold of the Phase 1 keys and use them to decrypt the Phase 2 packets in order to check. My gut feel is that Apple haven’t added PFS, they’ve just fixed the negotiation so it’s rejected cleanly.
It’s interesting that there’s a paper which raises concerns about widely deployed IPSec configurations, and within six months Apple are fielding a complete suite (they’ve made the same changes to the server, but I’m not using that code) of changes to close the whole issue down. They are playing hardball with the US government.
ian