Xojo.Net.NetException

Pierre_Vareilles · April 15, 2017, 2:57pm

Hello,

Does someone could tell me what means an Xojo.Net.NetException with the properties :

ErrorDomain          NSURLErrorDomain
ErrorNumber          -1200
Handle               &hxxxxxxxxxxx (not relevant)
LocalizedReason      An SSL error has occurred and a secure connection to the server cannot be made
Reason               An SSL error has occurred and a secure connection to the server cannot be made
UnderlyingError      Xojo.Net.NetException

The UnderlyingError is as follow :

ErrorDomain          kCFErrorDomainCFNetwork
ErrorNumber          -1200
Handle               &hxxxxxxxxxxx (not relevant)
LocalizedReason      An SSL error has occurred and a secure connection to the server cannot be made
Reason               An SSL error has occurred and a secure connection to the server cannot be made
UnderlyingError      Nil

I try from an iOS application made with Xojo to connect on one server running on one Raspberry Pi 3 and made with Xojo also. I use a secured connecion over ssl. I installed one Let’s Encrypt certificate one the server by compiling into the same file the certificate, the certification authority bundle and the private key. I’m pretty sure that everything is ok on the server side as I can send it with Safari handwritten requests and I get the expected answer thru secured connection.

The server is behind a DSL box with its ip address declared as DMZ. That means that all incoming traffic is redirected to the raspberry Pi. The Wan interface of the DSL box has one dns entry

I can’t find anything about error -1200

Thanks in advance for your insights

Pierre_Vareilles · April 16, 2017, 1:39pm

Probably the best day to have a sudden inspiration

I found something that did the trick at least for my case. This decrease a bit the level of security but this is better than nothing. Take a look here specially in NSAppTransportSecurity chapter

Added this key in the info.plist

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
	<key>NSAppTransportSecurity</key>
	<dict>
		<key>NSExceptionDomains</key>
		<dict>
			<key>mydomain.com</key>
			<dict>
				<key>NSExceptionRequiresForwardSecrecy</key>
				<false/>
			</dict>
		</dict>
	</dict>
</dict>
</plist>

@XOJO
Would be nice to have HTTPSocket in iOS Framework supporting certificate transparency

Greg_O_Lone · April 16, 2017, 3:52pm

[quote=326384:@Pierre Vareilles]@XOJO
Would be nice to have HTTPSocket in iOS Framework supporting certificate transparency[/quote]
Have you filed a feature request in Feedback?

Greg_O_Lone · April 16, 2017, 3:54pm

[quote=326384:@Pierre Vareilles]Probably the best day to have a sudden inspiration

I found something that did the trick at least for my case. This decrease a bit the level of security but this is better than nothing. Take a look here specially in NSAppTransportSecurity chapter

Added this key in the info.plist

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
	<key>NSAppTransportSecurity</key>
	<dict>
		<key>NSExceptionDomains</key>
		<dict>
			<key>mydomain.com</key>
			<dict>
				<key>NSExceptionRequiresForwardSecrecy</key>
				<false/>
			</dict>
		</dict>
	</dict>
</dict>
</plist>

@XOJO
Would be nice to have HTTPSocket in iOS Framework supporting certificate transparency[/quote]
Just looking at the docs, the reason to add this key (NSExceptionRequiresForwardSecrecy) is if the certificate on the server you are connecting to doesn’t support Forward Secrecy. That’s where your security problem lies, not with Xojo.

Pierre_Vareilles · April 18, 2017, 6:38am

I’ll as soon the bug about iOSContainerControl open event is resolved (<https://xojo.com/issue/44743> and <https://xojo.com/issue/44429>). No need to pile up new requests if you have no time to manage the old ones.

This is a certificate issued by Let’s Encrypt and I’d be surprised it doesn’t support PFS but why not. I probably missed something but the same code works fine in a desktop client application. I’ll investigate more deeply.

Michel_Bujardet · April 18, 2017, 8:04am

You should still file bug reports without second guessing Xojo’s engineers schedule. You never know how or when a bug can be fixed ahead of others, because they are working on that part of the framework.

The only way to see a bug fixed is to file a report.

Bug reports are not for your own consumption and project only, they serve the entire community’s good.

Greg_O_Lone · April 18, 2017, 9:06am

I just did a little more research and it could also be a server config issue.

Have your server admin research PFS and your web server (Apache or Nginx probably).

Pierre_Vareilles · April 19, 2017, 8:00am

[quote=326620:@Michel Bujardet]You should still file bug reports without second guessing Xojo’s engineers schedule. You never know how or when a bug can be fixed ahead of others, because they are working on that part of the framework.

The only way to see a bug fixed is to file a report.

Bug reports are not for your own consumption and project only, they serve the entire community’s good.[/quote]
Michel,

I totally agree with that in case of a bug. Here we’re talking about a new request in order to add new features. Personally and I insist on this, I’m unpleasantly surprised to see something like a race of new features leaving behind serious bugs. I repeat this is my vision of things and I believe Xojo should consider bugs management as a number one priority.

Michel_Bujardet · April 19, 2017, 8:50am

Pierre, I have been very vocal about what I considered important for iOS, so I have no issue about your conception of things.

But it is like it is. I don’t believe you or I can change the way the Xojo team works. Those are internal priorities we don’t have all the facts about. That should not prevent you from filing bug reports and feature requests. The only one punished will be you if you don’t.

Pierre_Vareilles · April 19, 2017, 9:17am

[quote=326624:@Greg O’Lone]I just did a little more research and it could also be a server config issue.

Have your server admin research PFS and your web server (Apache or Nginx probably).[/quote]
Greg,

I’m my own server admin !!! The server is no more than a Xojo standalone web app running under last Debian release. It is started with --secureport=xxxx and --maxsockets=0. The certificate is next to the binary. Don’t hesitate to ask should you need more details.

Greg_O_Lone · April 19, 2017, 10:56am

[quote=326808:@Pierre Vareilles]Greg,

I’m my own server admin !!! The server is no more than a Xojo standalone web app running under last Debian release. It is started with --secureport=xxxx and --maxsockets=0. The certificate is next to the binary. Don’t hesitate to ask should you need more details.[/quote]
Ah, well the reality is that you really shouldn’t be doing it that way. The http server in xojo is only http/1.0 and doesn’t negotiate modern SSL protocols to protect you the way Apache or Nginx would. My suggestion would be to put something in front of it acting as a reverse proxy or load balancer to handle SSL negotiation.