13 ms·

While other posts on this topic are too alarmist, this one is way too Apple apologetic for my taste. * There is no information on how often the validation happ

While other posts on this topic are too alarmist, this one is way too Apple apologetic for my taste. * There is no information on how often the validation happens. All this investigation concludes is that it doesn't happen when closing and immediately re-opening an app. Is it every week? Every reboot? Every hour? If it's less, that's essentially the same as doing it on every launch. * There is no justification for sending this information in cleartext. I don't follow the "browsers and loops" argument. This is a system-service that only has to trust a special Apple certificate, which can be distributed via other side-channels. * Many developers only publish a single app or a certain type of app. So it still is a significant information leak. It's really not much different from sending a app-specific hash. Think: remote therapy/healthcare apps, pornographic games, or Tor - which alone could get you into big trouble or on a watchlist in certain regions. I assume they will push a fix with better timeouts and availability detection. But Apple simply has to find a more privacy-aware system designs for this problem which does not leak this kind of data without an opt-in and also does not impact application startup times. (revocation lists?) I imagine this data might just be too attractive not to have. Such a "lazy" design is hard to imagine coming out of Apple otherwise.

throwawayg123 6y ago
Wait. Is it not common knowledge that Android and iOS log every application you open down to the exact millisecond you open and close them? Is it not common knowledge how telemetry works for the operating systems? They generally batch up a bunch of logs like this, encrypt them, compress them, and then send them to the mothership (hopefully when you're on WiFi).
- randyrand 6y ago
  don’t you need to enable analytics?
- deleted 6y ago
  [deleted]
- kenniskrag 6y ago
  first compressed and then encrypted. A good encryption is indistinguishable from random data.
  - xncl 6y ago
    That's why it's compressed before encryption?
    - avianlyric 6y ago
      Yeah, because encrypted data should be incompressible, as it should be indistinguishable from random data, which is also incompressible. Reality is a little different of course, and compression can cause problems for encryption because compressed data tends to be highly predictable (especially things like compression headers and compression dictionaries). This allows for potential “known/chosen plaintext” attacks on the encryption. Some classic examples of this type of attack are breaking Enigma (known plaintext, no compression) by assuming the content of some messages[0] and the more recent CRIME[1] attacks against TLS using compression to help produce a chosen plaintext. The simple solution in these scenarios is to avoid using compression completely. [0] https://www.quora.com/Did-the-inclusion-of-Heil-Hitler-at-the-end-of-encrypted-messages-lead-to-the-breaking-of-the-Enigma-code https://www.quora.com/Did-the-inclusion-of-Heil-Hitler-at-th... [1] https://en.m.wikipedia.org/wiki/CRIME https://en.m.wikipedia.org/wiki/CRIME
- viraptor 6y ago
  Logging and telemetry are completely separate use cases. For example to do some kind of battery use accounting you need some record of when exactly which app was active. And no, it's not widely known or documented - there is no good description of what telemetry exists or contains on iOS that I know of.
_qulr 6y ago
> There is no information on how often the validation happens. I wrote a blog post about this. My analysis indicates that Developer ID OCSP responses were previously cached for 5 minutes, but Apple changed it to half a day after Thursday's outage, probably to reduce traffic: https://lapcatsoftware.com/articles/ocsp.html https://lapcatsoftware.com/articles/ocsp.html
- saagarjha 6y ago
  5 minutes is an absurdly short cache time…
  - _qulr 6y ago
    Pure speculation from me, but my guess is that the intention is check an app on every launch, and the 5 minutes is there just to lower the chances of DoS from an app getting repeatedly launched for some reason.
  - Spivak 6y ago
    If you catch malware in the wild you don’t want to wait half a day for the cache to expire. Negative responses are typically cached for short periods of time. Can you imagine if people cached NXDOMAIN for half a day and someone creating a record had to wait 12 hours for it to go live because someone queried it?
    - _qulr 6y ago
      > If you catch malware in the wild you don’t want to wait half a day for the cache to expire. But if you have a cached OCSP response for the cert of a malware author, then you've already launched their app, so it's probably too late.
      - zepto 6y ago
        Plenty of kinds of malware are harmful each time they are launched, not just once.
olliej 6y ago
I feel Apple has done privacy well in so many cases, that the way this works is really disappointing :-/
- smnrchrds 6y ago
  Apple has done a fantastic PR job regarding privacy. I am more skeptical about the status of actual privacy given their iMessage situation and now this.
  - olliej 6y ago
    Their iMessage situation?
    - smnrchrds 6y ago
      They backup the private key to iCloud unless you manually disable backups. So even though iMessage is advertised as E2E encrypted, for the vast majority of users, Apple can read each and every message. (And even if you disable backups, Apple can still read most if not all of your messages, because the persons on the other side of the conversations have not disabled backups)
      - catlifeonmars 6y ago
        Can Apple read your iCloud storage? I’m not saying that it is, but shouldn’t that be encrypted at rest with a customer-specific key?
        EwanToo 6y ago
        I don't have any detailed knowledge of it, but I've seen various similar comments based on this article and similar ones: https://www.reuters.com/article/us-apple-fbi-icloud-exclusive/exclusive-apple-dropped-plan-for-encrypting-backups-after-fbi-complained-sources-idUSKBN1ZK1CT https://www.reuters.com/article/us-apple-fbi-icloud-exclusiv...
        6y ago
fiddlerwoaroof 6y ago
Isn’t OCSP an open standard for handling certificate revocations? The standard specifies plaintext, because the standard can’t assume that the client has a way to form an encrypted connection to the revocation list.
- remram 6y ago
  Wouldn't an anonymity scheme such as [1] work in this context? Send only part of the hash of the app's certificate, and have the server send you all possible revoked certificates? [1]: https://blog.cloudflare.com/validating-leaked-passwords-with-k-anonymity/ https://blog.cloudflare.com/validating-leaked-passwords-with...
  - est31 6y ago
    As the set of certificates is bounded and known by apple, they can also adopt crlite and just push all CRLs they have to all users, using CRLite. https://github.com/mozilla/crlite https://github.com/mozilla/crlite
    - remram 6y ago
      I assumed there were too many revoked certificates for something like this to be viable, but I'm not surprised it is. You probably can't update the whole list that often though, compared to Apple's current OCSP revalidate time of 5 min. [edit: seems "delta patches" are supported by crlite so maybe that can work too]
      - est31 6y ago
        > I assumed there were too many revoked certificates for something like this to be viable, but I'm not surprised it is. Given that Apple currently doesn't even encrypt the requests during transit, I think they just didn't pay much attention to the problem, which I think the main reason is why they haven't adopted it yet. As for the number of revoked certificates, I'm not sure it's larger than the number of revoked TLS certificates, given that there are way more websites out there than there are registered apple developers.
zamalek 6y ago
> [article] editing your /etc/hosts file. Personally, I wouldn’t suggest doing that as it prevents an important security feature from working. Exactly the apologetic that you are talking about. Everyone has a different security update cadence (e.g. patch Tuesday for Microsoft), but each application launch is not a reasonable one. Given Apple's recent propensity for banning developers who stand against them (whether you agree with those developers or not), this is aimed squarely at dissent.
- zepto 6y ago
  Apple hasn’t banned any developers who stand against them.
  - novok 6y ago
    I've noticed you have a very apple apologetic stance about this issue and are very active in replying to these articles, far more than the typical HN user. It's gotten to the point where I've noticed your username now. Why is that?
    - ethbr0 6y ago
      You'd be more aligned with HN values by refuting parent's point with examples than making ad hom attacks.
      - brabel 6y ago
        The accuser should also be held to the same standard. Without evidence those are just empty words.
        novok 6y ago
        Just look at our comment history, it's pretty easy lol
      - angry_octet 6y ago
        It is nevertheless the case that some users are VERY LOUD on particular topics, essentially repeating themselves on many leafs of the discussion. I find this very tiresome. It isn't an ad hom to point this out.
WesolyKubeczek 6y ago
Most "alarmist" articles have two points you cannot really ignore, not if you don't want to end up living in interesting times one day. 1) Even plain access logs — basically what a HTTP request, or a TCP connection can tell you — is a lot. Gather those for a couple of days, and you have a good map of the user. More so if you have an ID of machine and the actual executable hash. 2) "But we are the good guys" is a non-defense. Good guys can turn bad, they can be coerced by the bad guys, and 3) since the requests fly out in plain text, there is an unknown number of questionably-aligned guys in between capable of sniff your data. You only need one bad enough guy to get into serious trouble if that's what they want. This is not alarmist. It's just common sense. The same common sense that you use to avoid certain neighborhoods at certain times of night.
- sasaf5 6y ago
  @2) + good guys can be hacked.
  - sebastien_b 6y ago
    Or, simply assume that there really are no “good guys”.
    - amelius 6y ago
      Especially where money is involved.
      - boogies 6y ago
        IMO especially when stock holders wanting a monetary return on investment are involved. I give my money to the FSF every month, because they provide value to me, but not because I expect them to surreptitiously extract it from others and give it to me as cash dividends.
        sebastien_b 6y ago
        I think that's one of the big problems with public companies, especially those that have "regular people" as their main money maker (the "consumers") - invariably, the company's needs (duty) to make money for their real customers (the shareholders) will take precedence over what would be "the best thing" for consumers. I wish we could do away with the whole "public company" thing - just imagine how much better Facebook, Google, and countless other companies (yes, Apple too) would be if they were private, and more accountable to their users.
chrisoverzero 6y ago
> I don't follow the "browsers and loops" argument. To log in to my banking account, I need the correct password. No problem, I keep it in a password manager. To open the password manager, I need the correct password. No problem, I keep it in a password manager. To open the password manager, I need the correct password. No problem, I keep it in a password manager. To open the password manager, I need the correct password. No problem, I keep it in a password manager. And so on. Imagine that, but for “verifying the HTTPS connection”.
- lstamour 6y ago
  But there’s an easy fix. I use it with my password manager. To log in to my bank account, I need the correct password. No problem, I keep it in a password manager. To open the password manager, I need the correct password. No problem, I already know it. If I don’t know it, I look it up from a less secure source. Technically what I’m describing is that you can vary the behaviour of OCSP lookups such that if you’re already looking up an OCSP certificate to establish an SSL connection to an OCSP server, downgrade and check over HTTP only when trying to connect to the OCSP server itself. Yes, it would mean one more TLS connection to a random server. Yes, it would mean an extra OCSP lookup. But just one, and just for the OCSP server itself. Which means privacy is preserved in regards to which developer certificate you’re checking. It would be only checking Apple’s OCSP server certificate in the clear, which it could equally cache easily.
- kortex 6y ago
  TLS involves both cert checking (server is truly who they say they are and not MITM) and Diffie-Helman key exchange to set up session keys (messages are end-to-end encrypted). You can DH with an untrusted cert. It might be interceptable. HTTP is always interceptable. But there should be zero reason not to set this connection up with a full proper cert. HTTP is just mega sloppy. As others mentioned, you can bootstrap TLS by first checking OCSP (in the open) on your cert auth service, then use that opaque, freshly-checked connection to check the rest.
mcnichol 6y ago
Agreed. Call home features can be spoofed by a poisoning type of attack upstream in various forms. This is not bullet proof and a cop-out with a poor solution for security. You know who has effective call home features? Vendors that sell to major enterprises. It is a natural progression and a particularly nasty environment to live within. If they are legitimately trying to protect the brand through force or merely forcefully controlling the app ecosystem... it's an abusive relationship to be in. The fact this is not configurable without dead lettering the route is all they need to do to show tethering is something they consider as a viable security measure. I'll pass.
lowendbeholder 6y ago
The loop argument makes no sense at all. HTTP is being used as a transport for a base64-encoded payload, the actual process of veryfing the validity of the developer certificate is done by the service behind that Apple URL - not by the HTTP stack. There is no justification not to switch to HTTPS here.
- samatman 6y ago
  Yeah, that confused me as well. Even if there was some wrinkle about the loop argument that I didn't understand, and HTTPS is out: Apple could encrypt the base64 payload, and the sniffable info is reduced to which computer is phoning home, which is something that someone with the ability to middle comms probably knows already. "roll your own encryption and send it over HTTP" is a bad idea in general but... this is Apple, they can and do implement encryption. Why not here?
  - brabel 6y ago
    The OCSP RFC[1] specifies that if requests are made using HTTP, they MAY be protected via TLS or "some other lower-layer protocol". [1] https://tools.ietf.org/html/rfc6960#appendix-A.1 https://tools.ietf.org/html/rfc6960#appendix-A.1
- marcan_42 6y ago
  It's convention. With browsers, you wouldn't want to introduce a recursion point in TLS (we already have certificate chains, and now we'd get OCSP check chains and where does that terminate?). Apple just did what everyone else does for OCSP, in a way which is accepted practice for good reasons. Now in this specific instance, OCSP is being used in quite a different use case. For one, the plaintext issue is not a problem when browsing, as attackers can see what sites/certs you're accessing in the clear anyway (certificates are plaintext in TLS sessions), while app launch is an otherwise offline activity. So in this instance it makes sense for Apple to switch to HTTPS (and if they have OCSP on the server cert for that, that should go via HTTP to avoid loops or further issues). But what Apple did here is just standard practice, it's just that there happen to be good reasons to diverge from the standard here.
feralimal 6y ago
> But Apple simply has to find a more privacy-aware system designs for this problem which does not leak this kind of data without an opt-in and also does not impact application startup times. (revocation lists?) The idea that you need apple to certify the developer over the software you run on your phone is nonsense though. You don't do that on your computer, so why do you need to be nannied on your phone?
topranks 6y ago
Clear-text is the OSCP mechanics. This is nothing to do with Apple or MacOS. Potentially it could now be tackled with DNSSEC + DoH similar to the records ESNI/ECH puts in the DNS to encrypt initial HTTPS client hellos. But the loop issue is quite real. How can you validate the certificate the OSCP server gives you has not been revoked, using OSCP???
znpy 6y ago
> this one is way too Apple apologetic for my taste. I'm not surprised. Apple fanatics routinely deny evidence to support their sorta-religion.
- latexr 6y ago
  > Apple fanatics routinely deny evidence to support their sorta-religion. As do anti-Apple fanatics. That’s what being a “fanatic” means. You can say the same about gun fanatics, or meat fanatics, or vegetarian fanatics, or Android fanatics. It’s staggering how often people who are anti something fail to perceive the irony in behaving exactly in the manner they are decrying. Someone having a contrary opinion doesn’t make them a fanatic.
  - znpy 6y ago
    that's crude whataboutism. going back to the original topic, apple hardware/software, i've used apple hardware and software (company-issued macbook pro and iphone 7/8). The software is great as long as you want to stay within apple-defined boudaries. If you want to go outside that, it's an experience similar if not worse than using gnu/linux. The hardware is great when the machine is brand new but decays very quickly, it's not designed to be serviced by either end-users or specialized users or specialized shops -- you're supposed to return it to an apple store and pay an expensive price to basic maintenance. As an example, cleaning up the fans from dust is very important in those machines but you have to buy special hardware to take off the screws, and in generally you risk breaking something. Keyboards failed spectacularly in last gen, and apple waited like two years before fixing it. Audio is great, until it breaks. My macbook pro (15" top of the line) couldn't sustain full-audio, and distorted audio after ~30 sec of full volume audio (imagine that during a conference call in a meeting with other people). The screen is great, but the glass panel retained ALL of the fingerprints and it was a PITA to clean, i had to buy special glass-cleaning liquids. WTF. All the above issues appeared all shortly after the first year of life of the laptop. Call me an anti-apple fanatic, I don't care, but I expected more from a 3500+€ machine. At the new job i've been given a 13" dell latitude 7390. It works flawlessly, it rarely skips a beat and it has none of the problems stated above. Fuck Apple.
dwild 6y ago
> Such a "lazy" design is hard to imagine coming out of Apple otherwise. That's my biggest issue personally. There's a bit of information leak, but most wouldn't care and would just do the standard and be done with it. Firefox still uses OCSP in some case... My issue is that a company like Apple, which currently market itself as a company that care about privacy of their user, would have let this comes out of that same process that's supposed to care... and still hasn't said that was a mistake out of their process and that they are correcting it. They could easily use k-anonymity like HaveIBeenPwned, or even as push, which would means no cache, which is even better for their argument of security. There's nothing alarmist here, it's all alright, it would just means that this is the same false advertising that so many companies do, but still, is important to be aware of.
mrcybermac 6y ago
THANK YOU. I also see no reason that OCSP checks cannot support both HTTP and HTTPS. If there is some reason then the protocol should be split into two, one for unencrypted checks for things like SSL certs, and another for all other/ dev cert checks over HTTPS.

throwawayg123 6y ago

Wait. Is it not common knowledge that Android and iOS log every application you open down to the exact millisecond you open and close them? Is it not common knowledge how telemetry works for the operating systems? They generally batch up a bunch of logs like this, encrypt them, compress them, and then send them to the mothership (hopefully when you're on WiFi).

randyrand 6y ago
don’t you need to enable analytics?
deleted 6y ago
[deleted]
kenniskrag 6y ago
first compressed and then encrypted. A good encryption is indistinguishable from random data.
- xncl 6y ago
  That's why it's compressed before encryption?
  - avianlyric 6y ago
    Yeah, because encrypted data should be incompressible, as it should be indistinguishable from random data, which is also incompressible. Reality is a little different of course, and compression can cause problems for encryption because compressed data tends to be highly predictable (especially things like compression headers and compression dictionaries). This allows for potential “known/chosen plaintext” attacks on the encryption. Some classic examples of this type of attack are breaking Enigma (known plaintext, no compression) by assuming the content of some messages[0] and the more recent CRIME[1] attacks against TLS using compression to help produce a chosen plaintext. The simple solution in these scenarios is to avoid using compression completely. [0] https://www.quora.com/Did-the-inclusion-of-Heil-Hitler-at-the-end-of-encrypted-messages-lead-to-the-breaking-of-the-Enigma-code https://www.quora.com/Did-the-inclusion-of-Heil-Hitler-at-th... [1] https://en.m.wikipedia.org/wiki/CRIME https://en.m.wikipedia.org/wiki/CRIME
viraptor 6y ago
Logging and telemetry are completely separate use cases. For example to do some kind of battery use accounting you need some record of when exactly which app was active. And no, it's not widely known or documented - there is no good description of what telemetry exists or contains on iOS that I know of.

_qulr 6y ago

> There is no information on how often the validation happens. I wrote a blog post about this. My analysis indicates that Developer ID OCSP responses were previously cached for 5 minutes, but Apple changed it to half a day after Thursday's outage, probably to reduce traffic: https://lapcatsoftware.com/articles/ocsp.html https://lapcatsoftware.com/articles/ocsp.html

saagarjha 6y ago
5 minutes is an absurdly short cache time…
- _qulr 6y ago
  Pure speculation from me, but my guess is that the intention is check an app on every launch, and the 5 minutes is there just to lower the chances of DoS from an app getting repeatedly launched for some reason.
- Spivak 6y ago
  If you catch malware in the wild you don’t want to wait half a day for the cache to expire. Negative responses are typically cached for short periods of time. Can you imagine if people cached NXDOMAIN for half a day and someone creating a record had to wait 12 hours for it to go live because someone queried it?
  - _qulr 6y ago
    > If you catch malware in the wild you don’t want to wait half a day for the cache to expire. But if you have a cached OCSP response for the cert of a malware author, then you've already launched their app, so it's probably too late.
    - zepto 6y ago
      Plenty of kinds of malware are harmful each time they are launched, not just once.

olliej 6y ago

I feel Apple has done privacy well in so many cases, that the way this works is really disappointing :-/

smnrchrds 6y ago
Apple has done a fantastic PR job regarding privacy. I am more skeptical about the status of actual privacy given their iMessage situation and now this.
- olliej 6y ago
  Their iMessage situation?
  - smnrchrds 6y ago
    They backup the private key to iCloud unless you manually disable backups. So even though iMessage is advertised as E2E encrypted, for the vast majority of users, Apple can read each and every message. (And even if you disable backups, Apple can still read most if not all of your messages, because the persons on the other side of the conversations have not disabled backups)
    - catlifeonmars 6y ago
      Can Apple read your iCloud storage? I’m not saying that it is, but shouldn’t that be encrypted at rest with a customer-specific key?
      - EwanToo 6y ago
        I don't have any detailed knowledge of it, but I've seen various similar comments based on this article and similar ones: https://www.reuters.com/article/us-apple-fbi-icloud-exclusive/exclusive-apple-dropped-plan-for-encrypting-backups-after-fbi-complained-sources-idUSKBN1ZK1CT https://www.reuters.com/article/us-apple-fbi-icloud-exclusiv...
      - 6y ago

fiddlerwoaroof 6y ago

Isn’t OCSP an open standard for handling certificate revocations? The standard specifies plaintext, because the standard can’t assume that the client has a way to form an encrypted connection to the revocation list.

remram 6y ago
Wouldn't an anonymity scheme such as [1] work in this context? Send only part of the hash of the app's certificate, and have the server send you all possible revoked certificates? [1]: https://blog.cloudflare.com/validating-leaked-passwords-with-k-anonymity/ https://blog.cloudflare.com/validating-leaked-passwords-with...
- est31 6y ago
  As the set of certificates is bounded and known by apple, they can also adopt crlite and just push all CRLs they have to all users, using CRLite. https://github.com/mozilla/crlite https://github.com/mozilla/crlite
  - remram 6y ago
    I assumed there were too many revoked certificates for something like this to be viable, but I'm not surprised it is. You probably can't update the whole list that often though, compared to Apple's current OCSP revalidate time of 5 min. [edit: seems "delta patches" are supported by crlite so maybe that can work too]
    - est31 6y ago
      > I assumed there were too many revoked certificates for something like this to be viable, but I'm not surprised it is. Given that Apple currently doesn't even encrypt the requests during transit, I think they just didn't pay much attention to the problem, which I think the main reason is why they haven't adopted it yet. As for the number of revoked certificates, I'm not sure it's larger than the number of revoked TLS certificates, given that there are way more websites out there than there are registered apple developers.

zamalek 6y ago

> [article] editing your /etc/hosts file. Personally, I wouldn’t suggest doing that as it prevents an important security feature from working. Exactly the apologetic that you are talking about. Everyone has a different security update cadence (e.g. patch Tuesday for Microsoft), but each application launch is not a reasonable one. Given Apple's recent propensity for banning developers who stand against them (whether you agree with those developers or not), this is aimed squarely at dissent.

zepto 6y ago
Apple hasn’t banned any developers who stand against them.
- novok 6y ago
  I've noticed you have a very apple apologetic stance about this issue and are very active in replying to these articles, far more than the typical HN user. It's gotten to the point where I've noticed your username now. Why is that?
  - ethbr0 6y ago
    You'd be more aligned with HN values by refuting parent's point with examples than making ad hom attacks.
    - brabel 6y ago
      The accuser should also be held to the same standard. Without evidence those are just empty words.
      - novok 6y ago
        Just look at our comment history, it's pretty easy lol
    - angry_octet 6y ago
      It is nevertheless the case that some users are VERY LOUD on particular topics, essentially repeating themselves on many leafs of the discussion. I find this very tiresome. It isn't an ad hom to point this out.

WesolyKubeczek 6y ago

Most "alarmist" articles have two points you cannot really ignore, not if you don't want to end up living in interesting times one day. 1) Even plain access logs — basically what a HTTP request, or a TCP connection can tell you — is a lot. Gather those for a couple of days, and you have a good map of the user. More so if you have an ID of machine and the actual executable hash. 2) "But we are the good guys" is a non-defense. Good guys can turn bad, they can be coerced by the bad guys, and 3) since the requests fly out in plain text, there is an unknown number of questionably-aligned guys in between capable of sniff your data. You only need one bad enough guy to get into serious trouble if that's what they want. This is not alarmist. It's just common sense. The same common sense that you use to avoid certain neighborhoods at certain times of night.

sasaf5 6y ago
@2) + good guys can be hacked.
- sebastien_b 6y ago
  Or, simply assume that there really are no “good guys”.
  - amelius 6y ago
    Especially where money is involved.
    - boogies 6y ago
      IMO especially when stock holders wanting a monetary return on investment are involved. I give my money to the FSF every month, because they provide value to me, but not because I expect them to surreptitiously extract it from others and give it to me as cash dividends.
      - sebastien_b 6y ago
        I think that's one of the big problems with public companies, especially those that have "regular people" as their main money maker (the "consumers") - invariably, the company's needs (duty) to make money for their real customers (the shareholders) will take precedence over what would be "the best thing" for consumers. I wish we could do away with the whole "public company" thing - just imagine how much better Facebook, Google, and countless other companies (yes, Apple too) would be if they were private, and more accountable to their users.

chrisoverzero 6y ago

> I don't follow the "browsers and loops" argument. To log in to my banking account, I need the correct password. No problem, I keep it in a password manager. To open the password manager, I need the correct password. No problem, I keep it in a password manager. To open the password manager, I need the correct password. No problem, I keep it in a password manager. To open the password manager, I need the correct password. No problem, I keep it in a password manager. And so on. Imagine that, but for “verifying the HTTPS connection”.

lstamour 6y ago
But there’s an easy fix. I use it with my password manager. To log in to my bank account, I need the correct password. No problem, I keep it in a password manager. To open the password manager, I need the correct password. No problem, I already know it. If I don’t know it, I look it up from a less secure source. Technically what I’m describing is that you can vary the behaviour of OCSP lookups such that if you’re already looking up an OCSP certificate to establish an SSL connection to an OCSP server, downgrade and check over HTTP only when trying to connect to the OCSP server itself. Yes, it would mean one more TLS connection to a random server. Yes, it would mean an extra OCSP lookup. But just one, and just for the OCSP server itself. Which means privacy is preserved in regards to which developer certificate you’re checking. It would be only checking Apple’s OCSP server certificate in the clear, which it could equally cache easily.
kortex 6y ago
TLS involves both cert checking (server is truly who they say they are and not MITM) and Diffie-Helman key exchange to set up session keys (messages are end-to-end encrypted). You can DH with an untrusted cert. It might be interceptable. HTTP is always interceptable. But there should be zero reason not to set this connection up with a full proper cert. HTTP is just mega sloppy. As others mentioned, you can bootstrap TLS by first checking OCSP (in the open) on your cert auth service, then use that opaque, freshly-checked connection to check the rest.

mcnichol 6y ago

Agreed. Call home features can be spoofed by a poisoning type of attack upstream in various forms. This is not bullet proof and a cop-out with a poor solution for security. You know who has effective call home features? Vendors that sell to major enterprises. It is a natural progression and a particularly nasty environment to live within. If they are legitimately trying to protect the brand through force or merely forcefully controlling the app ecosystem... it's an abusive relationship to be in. The fact this is not configurable without dead lettering the route is all they need to do to show tethering is something they consider as a viable security measure. I'll pass.

lowendbeholder 6y ago

The loop argument makes no sense at all. HTTP is being used as a transport for a base64-encoded payload, the actual process of veryfing the validity of the developer certificate is done by the service behind that Apple URL - not by the HTTP stack. There is no justification not to switch to HTTPS here.

samatman 6y ago
Yeah, that confused me as well. Even if there was some wrinkle about the loop argument that I didn't understand, and HTTPS is out: Apple could encrypt the base64 payload, and the sniffable info is reduced to which computer is phoning home, which is something that someone with the ability to middle comms probably knows already. "roll your own encryption and send it over HTTP" is a bad idea in general but... this is Apple, they can and do implement encryption. Why not here?
- brabel 6y ago
  The OCSP RFC[1] specifies that if requests are made using HTTP, they MAY be protected via TLS or "some other lower-layer protocol". [1] https://tools.ietf.org/html/rfc6960#appendix-A.1 https://tools.ietf.org/html/rfc6960#appendix-A.1
marcan_42 6y ago
It's convention. With browsers, you wouldn't want to introduce a recursion point in TLS (we already have certificate chains, and now we'd get OCSP check chains and where does that terminate?). Apple just did what everyone else does for OCSP, in a way which is accepted practice for good reasons. Now in this specific instance, OCSP is being used in quite a different use case. For one, the plaintext issue is not a problem when browsing, as attackers can see what sites/certs you're accessing in the clear anyway (certificates are plaintext in TLS sessions), while app launch is an otherwise offline activity. So in this instance it makes sense for Apple to switch to HTTPS (and if they have OCSP on the server cert for that, that should go via HTTP to avoid loops or further issues). But what Apple did here is just standard practice, it's just that there happen to be good reasons to diverge from the standard here.

feralimal 6y ago

> But Apple simply has to find a more privacy-aware system designs for this problem which does not leak this kind of data without an opt-in and also does not impact application startup times. (revocation lists?) The idea that you need apple to certify the developer over the software you run on your phone is nonsense though. You don't do that on your computer, so why do you need to be nannied on your phone?

topranks 6y ago

Clear-text is the OSCP mechanics. This is nothing to do with Apple or MacOS. Potentially it could now be tackled with DNSSEC + DoH similar to the records ESNI/ECH puts in the DNS to encrypt initial HTTPS client hellos. But the loop issue is quite real. How can you validate the certificate the OSCP server gives you has not been revoked, using OSCP???

znpy 6y ago

> this one is way too Apple apologetic for my taste. I'm not surprised. Apple fanatics routinely deny evidence to support their sorta-religion.

latexr 6y ago
> Apple fanatics routinely deny evidence to support their sorta-religion. As do anti-Apple fanatics. That’s what being a “fanatic” means. You can say the same about gun fanatics, or meat fanatics, or vegetarian fanatics, or Android fanatics. It’s staggering how often people who are anti something fail to perceive the irony in behaving exactly in the manner they are decrying. Someone having a contrary opinion doesn’t make them a fanatic.
- znpy 6y ago
  that's crude whataboutism. going back to the original topic, apple hardware/software, i've used apple hardware and software (company-issued macbook pro and iphone 7/8). The software is great as long as you want to stay within apple-defined boudaries. If you want to go outside that, it's an experience similar if not worse than using gnu/linux. The hardware is great when the machine is brand new but decays very quickly, it's not designed to be serviced by either end-users or specialized users or specialized shops -- you're supposed to return it to an apple store and pay an expensive price to basic maintenance. As an example, cleaning up the fans from dust is very important in those machines but you have to buy special hardware to take off the screws, and in generally you risk breaking something. Keyboards failed spectacularly in last gen, and apple waited like two years before fixing it. Audio is great, until it breaks. My macbook pro (15" top of the line) couldn't sustain full-audio, and distorted audio after ~30 sec of full volume audio (imagine that during a conference call in a meeting with other people). The screen is great, but the glass panel retained ALL of the fingerprints and it was a PITA to clean, i had to buy special glass-cleaning liquids. WTF. All the above issues appeared all shortly after the first year of life of the laptop. Call me an anti-apple fanatic, I don't care, but I expected more from a 3500+€ machine. At the new job i've been given a 13" dell latitude 7390. It works flawlessly, it rarely skips a beat and it has none of the problems stated above. Fuck Apple.

dwild 6y ago

> Such a "lazy" design is hard to imagine coming out of Apple otherwise. That's my biggest issue personally. There's a bit of information leak, but most wouldn't care and would just do the standard and be done with it. Firefox still uses OCSP in some case... My issue is that a company like Apple, which currently market itself as a company that care about privacy of their user, would have let this comes out of that same process that's supposed to care... and still hasn't said that was a mistake out of their process and that they are correcting it. They could easily use k-anonymity like HaveIBeenPwned, or even as push, which would means no cache, which is even better for their argument of security. There's nothing alarmist here, it's all alright, it would just means that this is the same false advertising that so many companies do, but still, is important to be aware of.

mrcybermac 6y ago

THANK YOU. I also see no reason that OCSP checks cannot support both HTTP and HTTPS. If there is some reason then the protocol should be split into two, one for unencrypted checks for things like SSL certs, and another for all other/ dev cert checks over HTTPS.