4 ms·

I don't get why they're delaying this. My understanding was that fully disabling ATS would require a justification. That makes sense. It's annoying to have to

by orbitur 10y ago

I don't get why they're delaying this. My understanding was that fully disabling ATS would require a justification. That makes sense. It's annoying to have to audit your apps and enumerate the endpoints, but as long as Apple didn't require justification for explicit domain exceptions, everything should've been fine.

deleted 10y ago
[deleted]
eugeniub 10y ago
That's not quite right. You will still have to justify every domain exception. > By the end of 2016, when your apps communicate with your own server back ends, they must do so using a secure TLS channel using TLS 1.2, unless the data being communicated is bulk data such as media streaming and data that’s already encrypted. https://nakedsecurity.sophos.com/2016/06/17/apple-ios-to-require-https-for-apps-by-january/ https://nakedsecurity.sophos.com/2016/06/17/apple-ios-to-req...
gilgoomesh 10y ago
> but as long as Apple didn't require justification for explicit domain exceptions The previous plan was they they were going to require justification for every domain exception. Further, they were going to require justification if you were already using HTTP Live Streaming... Apple's own protocol which is written to use AES encrypted segments over plain HTTP. They were going to require justification for peer connections that have to jump through hoops to get URLSession recognize their self-signed certificates. This one in particular is still affecting one of my apps. It's not always possible to force peer certificates to be accepted, making HTTPS between peers very difficult (seemingly impossible) at times. I'm not saying that these things can't be done but I think Apple underestimated the number of systems affected and the justifications and reasons involved. HTTPS is fundamentally not "everywhere", despite its prevalence in larger systems.
- valarauca1 10y ago
  You really shouldn't do HTTPS if you can't complete the chain of trust with a peer. If one is doing some multi-cast multi-tenant swarm stuff... why is the data private? It seems like a lot of people have access.
  - gilgoomesh 10y ago
    In my case, your peers are your friends. You use a pairing code (part of the SHA256 fingerprint) to accept the certificate (so you need to see the other person's screen and have agreement with the fingerprint) and then you can use indefinitely. It's great until the whole connection fails because some element in the system works with Certificate Authority certs-only – issues we're still working on and certainly won't be finished by Jan 1.
    - valarauca1 10y ago
      The finger print is public. There is literally zero security in this system anyone can hijack it
      - JamesB7 10y ago
        Public keys are public. Just because you don't understand cryptography doesn't make a system bad. There's nothing magical about certificate authorities. There are many ways to establish secure connections without them.

by orbitur 10y ago

deleted 10y ago

[deleted]

eugeniub 10y ago

That's not quite right. You will still have to justify every domain exception. > By the end of 2016, when your apps communicate with your own server back ends, they must do so using a secure TLS channel using TLS 1.2, unless the data being communicated is bulk data such as media streaming and data that’s already encrypted. https://nakedsecurity.sophos.com/2016/06/17/apple-ios-to-require-https-for-apps-by-january/ https://nakedsecurity.sophos.com/2016/06/17/apple-ios-to-req...

gilgoomesh 10y ago

> but as long as Apple didn't require justification for explicit domain exceptions The previous plan was they they were going to require justification for every domain exception. Further, they were going to require justification if you were already using HTTP Live Streaming... Apple's own protocol which is written to use AES encrypted segments over plain HTTP. They were going to require justification for peer connections that have to jump through hoops to get URLSession recognize their self-signed certificates. This one in particular is still affecting one of my apps. It's not always possible to force peer certificates to be accepted, making HTTPS between peers very difficult (seemingly impossible) at times. I'm not saying that these things can't be done but I think Apple underestimated the number of systems affected and the justifications and reasons involved. HTTPS is fundamentally not "everywhere", despite its prevalence in larger systems.

valarauca1 10y ago
You really shouldn't do HTTPS if you can't complete the chain of trust with a peer. If one is doing some multi-cast multi-tenant swarm stuff... why is the data private? It seems like a lot of people have access.
- gilgoomesh 10y ago
  In my case, your peers are your friends. You use a pairing code (part of the SHA256 fingerprint) to accept the certificate (so you need to see the other person's screen and have agreement with the fingerprint) and then you can use indefinitely. It's great until the whole connection fails because some element in the system works with Certificate Authority certs-only – issues we're still working on and certainly won't be finished by Jan 1.
  - valarauca1 10y ago
    The finger print is public. There is literally zero security in this system anyone can hijack it
    - JamesB7 10y ago
      Public keys are public. Just because you don't understand cryptography doesn't make a system bad. There's nothing magical about certificate authorities. There are many ways to establish secure connections without them.