CURL URLLoader does not support SNI, requests fail with IOError. about nme HOT 11 CLOSED

Perhaps option 1 is the best one for the moment, we use AxTLS, not OpenSSL, and I forget if we are using TLS, perhaps not. In this case, even with a recent cURL library (which we updated not too long ago) we still would not be able to access the data. On the other hand, there is the assumption that SSL should be secure, do you think this is a must?

from nme.

Because of the shortage of IPv4 addresses I think we'll find this becomes more and more common, especially for HTTPS sites with multiple subdomains sharing the same IP. In my case it's preventing me from making encrypted API calls between the app + website altogether.

I believe option 1 is reasonable for my case where I control both the app & website. But for an app that allows the user to open arbitrary URLs it would definitely be a serious security issue. So it might not be a good idea to silently disable SSL verification by default.

Is there an easy way we could make it a property of URLLoader, or project.xml setting or similar?

from nme.

Silly me :)

AxTLS, is, of course, designed for TLS support, so that should mean we need only to ensure that AxTLS has SNI support. Our cURL library should be new enough.

A month ago, someone created a patch for AxTLS with SNI support. Perhaps this would be the best path to look up?

dsheets/axtls#2

from nme.

This repo seems to have the latest axTLS 1.4.9 with the SNI patch in it:
https://github.com/tessel/runtime/tree/master/deps/axtls

My guess is this needs to go into nme-dev/project/tars/ but I've no idea how to then build the nme-dev libs for all the platforms. Might need a nudge in the right direction with this one :-)

from nme.

OK now I'm the silly one... just read the nme-dev/README :-S Giving it a try.

from nme.

No dice it appears...

The above patch adds SNI support to axTLS, but curl still doesn't know how to use it. We'd need to also patch curl/lib/vtl/axtls.c so curl knows to use SNI with axTLS and also set the hostname via the axTLS patch.

I spent some time looking through the curl code, and it seems I'm way too SSL ignorant to make any sense of it.

I'm guessing there's a good reason (easier portability?) for using axTLS instead if OpenSSL?

from nme.

Looks like:

http://curl.haxx.se/docs/ssl-compared.html

BSD license, very small codebase. Oh, there's always some problem, isn't there? :)

OpenSSL isn't purely off the table, but performance and whether it compiles well and integrates in are important. I've held to "if it ain't broke don't fix it" but maybe it's broke :/

from nme.

Yeah this is a tough one. What do you suggest for the next step? Finding a way to optionally disabled the VERIFYHOST or trying to compile against openssl for all platforms?

from nme.

@bazzisoft Do you still need help with this issue?

from nme.

@thomasuster Not for my project, I used a static IP as a workaround. Still seems worthwhile getting it fixed at some point but it's not urgent for my use case. Thanks for following up!

from nme.

Cool, yea I'd rather close for now until someone has the urge to help this along. Aloha

from nme.