4 ms·
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 dat
by mvip 4y ago
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 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/ https://docs.rs/httpdate/0.3.2/httpdate/
- ianai 4y agoDo you just pipe that into a date set command?
- mvip 4y agoNo, 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 https://linux.die.net/man/8/htpdate).
- ThePowerOfFuet 4y agoWhy does Screenly have their API available on port 80 at all? Great way to leak cookies or tokens...
- mvip 4y agoWe 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://api.screenlyapp.com HTTP/1.1 301 Moved Permanently Date: Fri, 30 Dec 2022 09:01:44 GMT [...]
- ThePowerOfFuet 4y agoRegardless 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.
- tjoff 4y agoBut that assumes you have regular dns? So then you could just query one of the ntp servers using dns instead?
- mvip 4y agoAh, 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 http://1.1.1.1 | grep Date