Hacker News Reader

Comment by easytiger | Hacker News Reader

Wait.. they are saying the app itself is making NTP requests?

> Confirmed - starting up the iOS Snapchat app does a lookup to the domains you listed, and then sends NTP to every unique IP. Around 35-60 different IPs.

Hmm. Is that a fraud prevention thing or something? No way on earth a user app should be getting its own time

View on HN

Snapchat have a lot of "fraud protection" in the form of time sensitive tokens hashed with secret keys generated by strange .so libraries. This is used to keep third party apps from using their API, obviously a lot of user's devices have incorrect clocks, so when they reduced the secret token time frame lots of users probably started getting API errors, so this is their attempt at a solution.

Thank you! This is the most reasonable answer I've seen in the thread so far.

> Is that a fraud prevention thing or something?

See my other post here, and the problems in the (third party) iOS NTP library "features" and its use.

There "createAssociations" in that library without any parameters contacts all the IPs behind the big domain list of the NTP servers!

And according to the forum every IP is contacted -- behind one server name there are 3-4 servers in the DNS in this case, I get 31 server! Real "distributed denial of service" attack.

Just to be clear, this is a 3rd party library not part of iOS itself.

Yes, thank you, the third party library that Snapchat used without even thinking what it does by using some (wrong!) defaults. I thought it was obvious from the links I've given. I've edited my posts to name it as such.

I've never used Snapchat but I believe one of its features is time-expiring photos. If they do the expiration in the client then this may be a way to check if a user is getting around it by setting the system clock backwards.

NTP doesn't cryptographically verify the time. All you do is have your router redirect these NTP requests to your own server, which is set to serve the wrong time.

Ironically, part of an HTTPS handshake involves sharing the server time in a cryptographically-verifiable manner. I am not sure why they don't use that! https://github.com/ioerror/tlsdate

Well, I didn't say it was a good way ;)

That only works for current TLS. Version 1.3 makes sending the server date optional.

Optional, but does anyone turn it off? They control their own servers, anyway.

Optional for the implementations. So basically your ssl library is unlikely to do it. And at that point having a "getTime()" API call in your service is simpler than having a custom patched SSL implementation.

Oh, common SSL libraries don't do it? Even then you can probably rely on a Date header being attached to all your existing requests.

> No way on earth a user app should be getting its own time

This practice is becoming increasingly common for "time-sensitive applications":

https://eng.lyft.com/freezing-time-6ebe8ffe3321

Just checked, at least they use "time.apple.com" as default, and the default "maximum of servers" is 5.

https://github.com/lyft/Kronos/blob/master/Sources/NTPClient...

The third-party library used by Snapchat didn't have any "maximum of servers" (using 30 at once(!)) and defaulted to many in the ntp.org pool, across all the continents!

The report does say "app" specifically. So I assume yes.

This was an error on their behalf.

http://mailman.nanog.org/pipermail/nanog/2016-December/08962...

Reply on news.ycombinator.com