Disabling App Transport Security entirely is a bad idea

[andreas0]

Alfred 2.8.1 disabled App Transport Security entirely.

 

This is a bad idea and shouldn't be done this way. Alfred should use ATS for connections to it's own servers at least.

Apple provides a documentation on how to implement this here.

 

Alfred is not the only app that opted out entirely. A lot of developers choose this option at the moment - but they really shoudn't...

 

More details on this topic:

• https://www.dzombak.com/blog/2015/09/Nobody-is-using-App-Transport-Security--what-s-next-.html
• http://ste.vn/2015/06/10/configuring-app-transport-security-ios-9-osx-10-11/

[Andrew]

 

This is a bad idea and shouldn't be done this way. Alfred should use ATS for connections to it's own servers at least.

 

 

I'm moving this to noted, but it's not a bug.

 

Alfred's preferences app doesn't allow arbitrary loads, uses ATS, and this is the part of Alfred which does the auto updating. It's also worth noting that CacheFly was using TLS 1.0 at the point that ATS become relevant. I've worked with CacheFly and they have been very efficient in updating their CDN to use TLS 1.2 which allows me to remove the min requirement of TLS 1.0 for the CacheFly domain from Alfred's preferences making connections to any alfredapp.com domain / subdomain (for updating) use ATS.

 

The reason Alfred allows arbitrary connections for domains other than auto updating with alfredapp.com is listed in one of the links you've provided:

 

Essentially, there is no way for Alfred to know what domains Alfred's workflows need to connect to... much like a web browser, therefore HAS to allow arbitrary loads for network based workflows to work.

 

This is currently a temporary exception and ATS will be fully enabled in Alfred in the future once the workflows catch up.

 

Cheers,

Andrew

[deanishe]

ATS will be fully enabled in Alfred in the future

 

Out of interest, how does this affect workflows?

 

My understanding of ATS is that it only applies to Cocoa HTTP libraries and types. Would I be right in thinking it would apply to workflows that use Cocoa libraries, but not any others?

 

That is to say, regardless of what Andrew does with Alfred, the system Python on everything before El Cap (i.e. pre-Python 2.7.9) will still perform no validation of SSL/TLS certificates. (Neither does file_get_contents() in PHP, AFAIK.)

[Andrew]

 

Out of interest, how does this affect workflows?

 

My understanding of ATS is that it only applies to Cocoa HTTP libraries and types. Would I be right in thinking it would apply to workflows that use Cocoa libraries, but not any others?

 

That is to say, regardless of what Andrew does with Alfred, the system Python on everything before El Cap (i.e. pre-Python 2.7.9) will still perform no validation of SSL/TLS certificates. (Neither does file_get_contents() in PHP, AFAIK.)

 

I'm certain that you are right, but I wanted to err on the side of caution for now in my decisions for ATS in the short term to prevent any interruption in service.

 

This will be analysed deeper in the future

 

Cheers,

Andrew

[deanishe]

I had a play with ATS to see how "hard" its requirements are.
 
As best as I can tell, its requirements only apply to the application itself. Subprocesses run via NSTask are unaffected by ATS. There is one interesting exception: If you try to run a program that uses NSURLSession and is located in the Xcode project directory, ATS will be applied. You can bundle the same program with your app's resources, or run it from anywhere else, and ATS restrictions are not applied.