On Thu, 2011-12-29 at 10:59 +0000, David Woodhouse wrote: > That looks better. My only remaining gripe is that you expose the > 'keystore' key type even when it's not available. That should be in > #ifdef ANDROID too, shouldn't it? > > We should also possibly update the man page? Looking back at this... did I ever get a patch which addressed the above? I don't seem to have actually committed anything. > > > Also, I wonder if we're using the Android keystore correctly. It looks > > > like you are extracting the private key from the keystore and > > > *importing* it into OpenSSL. But if it's a TPM or crypto token or > > > something like that, it shouldn't *allow* that operation. It'll *use* > > > the key for you, but it won't just *give* it to you. And a well-designed > > > OS key store shouldn't allow that either. Are you *sure* that's what > > > you're supposed to do? > > > > Pretty sure, the android keystore is basically just a database service > > for storing key-value pairs used for security purposes (wifi passwords > > certificates, etc). > > Hm, that sounds like a bloody stupid design for a key store that can > store SSL keys. Either that, or storing SSL keys in it is > inappropriate. Having seen a little more of Android, I am no longer surprised by such stupid design decisions :( > > > Also, have you looked at the Android authentication GUI at > > > https://github.com/srinathduraisamy/OpenConnect ? > > > > What is this app supposed to do? With our vpn concentrator it just says > > 'No peer certificate'. Srinath has updated it to handle unknown certificates gracefully now. As I said before, it basically handles the authentication part up to obtaining the cookie that you need to connect with. I think it would be a good basis for a root-less app which uses the ICS VPN service. The only complication is that Android's VPN service handles the 'route all packets through the VPN *except* the ones we're actually trying to send to the VPN server' thing differently. Rather than just telling it the IP address of the server and letting it set up a host-specific route through the "real" network, as vpnc-script does, we instead "protect" the socket(s) that connect us to the server: http://developer.android.com/reference/android/net/VpnService.html#protect%28int%29 I'm not entirely sure what that does behind the scenes; perhaps SO_BINDTODEVICE or something like that? So we'll need to make sure that the sockets openconnect uses for talking to the server are "protected". One option is to create the sockets *for* it and pass them in (with --cstp-fd=5 --dtls-fd=6 or something like that on the command line). But that won't work well if a connection is lost and openconnect has to make a new one. Perhaps it could *exit* then, and make us re-invoke it? If handling the socket protection from C code is hard, it might make sense just to reimplement OpenConnect *completely* in Java. The TCP part is dead easy, and if we can do Cisco's speshul version of DTLS from Java too (perhaps by calling OpenSSL?) then that shouldn't be too hard either. -- dwmw2 -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 6171 bytes Desc: not available URL: <http://lists.infradead.org/pipermail/openconnect-devel/attachments/20120505/ce9ef806/attachment.bin>
