Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

We've seen this (and similar TLS related issues) a fair bit at Screenly when working with Raspberry Pis.

The best workaround that we've found is to use the date in a HTTP Header to set the initial time (if we detect this condition):

$ curl -sI http://api.screenlyapp.com | grep Date

Date: Fri, 30 Dec 2022 08:43:56 GMT

With this set, you should be able to trigger the initial NTP service to start and set the date.

There's a Rust library here that can parse these dates for you: https://docs.rs/httpdate/0.3.2/httpdate/



But that assumes you have regular dns?

So then you could just query one of the ntp servers using dns instead?


Ah, good point! That was just to show the header. We have a bit different logic in our actual application where we check a number of IPs too, including 1.1.1.1:

$ curl -sI http://1.1.1.1 | grep Date


Do you just pipe that into a date set command?


No, we parse it and set it over DBUS. If you want to do something more turnkey, take a look at htpdate (https://linux.die.net/man/8/htpdate).


Why does Screenly have their API available on port 80 at all? Great way to leak cookies or tokens...


We obviously don't use HTTP for serving our API. The HTTP end-point is just a 301, but it still contains the Date field:

$ curl -I http://api.screenlyapp.com

HTTP/1.1 301 Moved Permanently

Date: Fri, 30 Dec 2022 09:01:44 GMT [...]


Regardless of it being a 301, the cookie or token is already sent, and thus already burned, by the time the response code is returned.

Your API should not even be listening on port 80, period.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: