Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.
Sign upSecure time syncronisation (with tlsdate) #2342
Comments
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
adrelanos
Sep 29, 2016
Member
tlsdate has been developed by Jacob Appelbaum (@ioerror). Due to the recent news surrounding him, him now doing no more public communication, I think it is safe to assume he will stay away from the computer security and development community. So it is probably save to assume all of his projects abandoned.
|
tlsdate has been developed by Jacob Appelbaum (@ioerror). Due to the recent news surrounding him, him now doing no more public communication, I think it is safe to assume he will stay away from the computer security and development community. So it is probably save to assume all of his projects abandoned. |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
adrelanos
Sep 29, 2016
Member
Disclaimer: As a developer of sdwdate I am probably biased.
https://github.com/ioerror/tlsdate
Pros:
- uses seccomp
written by Jacob Appelbaum (security researcher; The Tor Project staff member)Due to the recent news now probably abandoned.
Cons:
- Only native SSL CA pinning support. No direct SSL certificate pinning support.
- Does not distribute trust. (As for example sdwdate does.)
- ioerror/tlsdate#112
- ioerror/tlsdate#143 (comment)
- The single time source can send by error or by malicious intent send wrong time replies.
- Produces clock jumps, which confuses various applications. Does not gradually adjust as for example sdwdate does with Slow Clock Adjuster. (sclockadj)
- Cannot connect to (most) Tor hidden services, because most of those do not support SSL.
- Minor: command line parser doesn't fail closed on extraneous / unknown command line parameters
- ioerror/tlsdate#158
- not that important in the absence of bugs in tlsdate, but the safer behavior for tlsdate would be to fail closed on on extraneous / unknown command line parameters.
- Likely denial of service issue
|
Disclaimer: As a developer of sdwdate I am probably biased. https://github.com/ioerror/tlsdate Pros:
Cons:
|
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
adrelanos
Sep 29, 2016
Member
A great deal was spend on secure time synchronization by @HulaHoopWhonix and me.
- https://www.whonix.org/wiki/Sdwdate
- https://www.whonix.org/wiki/Dev/TimeSync
- https://www.whonix.org/wiki/Time_Attacks
Help with ticket Qubes-Whonix-Gateway as ClockVM, more generally, sdwdate tickets or sdwdate-gui tickets would be appreciated!
|
A great deal was spend on secure time synchronization by @HulaHoopWhonix and me.
Help with ticket Qubes-Whonix-Gateway as ClockVM, more generally, sdwdate tickets or sdwdate-gui tickets would be appreciated! |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
rugk
Sep 29, 2016
Wait a minute: What is currently used by QubesOS? Sdwdate?
Personally, I'd say sdwdate looks nice too. So if it has already been implemented feel free to close this issue.
rugk
commented
Sep 29, 2016
•
|
Wait a minute: What is currently used by QubesOS? Sdwdate? Personally, I'd say sdwdate looks nice too. So if it has already been implemented feel free to close this issue. |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
rugk
Sep 29, 2016
Cannot connect to (most) Tor hidden services, because most of those do not support SSL.
Facebook does.
rugk
commented
Sep 29, 2016
Facebook does. |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
adrelanos
Sep 29, 2016
Member
rugk:
Wait a minute: What is currently used by QubesOS? Sdwdate?
Still NTP. Only Qubes-Whonix uses sdwdate. That's what the ticket I
linked above is for.
Personally, I'd say sdwdate looks nice too. So if it already has been implemented feel free to close this issue.
I guess we can use a ticket to fix secure time synchronization.
|
rugk:
Still NTP. Only Qubes-Whonix uses sdwdate. That's what the ticket I
I guess we can use a ticket to fix secure time synchronization. |
andrewdavidwong
added
enhancement
help wanted
C: core
labels
Sep 30, 2016
andrewdavidwong
added this to the Release 4.0 milestone
Sep 30, 2016
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
rugk
Sep 30, 2016
tlsdate isn't abandoned, stop slandering jacob
I think the personal issues of a developer do not matter. It is his project, which matters here, so let us looking at the facts.
- last commit in 2015
- in the last month only one new issue has been opened (except of my own issue)
This looks a bit like the project is not developed actively anymore.
To be fair I'll ping @ioerror.
rugk
commented
Sep 30, 2016
I think the personal issues of a developer do not matter. It is his project, which matters here, so let us looking at the facts.
This looks a bit like the project is not developed actively anymore. |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
rugk
Oct 4, 2016
FYI there is also a new protocol by @agl for secure time synchronisation: roughtime (more information).
rugk
commented
Oct 4, 2016
|
FYI there is also a new protocol by @agl for secure time synchronisation: roughtime (more information). |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
jpouellet
Nov 14, 2016
Contributor
OpenNTPD is relevant here and IMO should be considered.
It has a much better security track record than ntp.org ntpd.
Relevant feature here, from the OpenNTPD man page:
ntpd(8) can be configured to query the ‘Date’ from trusted HTTPS servers via TLS. This time information is not used for precision but acts as an authenticated constraint, thereby reducing the impact of unauthenticated NTP man-in-the-middle attacks. Received NTP packets with time information falling outside of a range near the constraint will be discarded and such NTP servers will be marked as invalid.
-- http://man.openbsd.org/OpenBSD-current/man5/ntpd.conf.5#CONSTRAINTS
|
OpenNTPD is relevant here and IMO should be considered. It has a much better security track record than ntp.org ntpd. Relevant feature here, from the OpenNTPD man page:
|
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
marmarek
Nov 14, 2016
Member
Indeed interesting. Any idea why it isn't packaged in Fedora?
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
|
Indeed interesting. Any idea why it isn't packaged in Fedora? Best Regards, |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
jpouellet
Nov 15, 2016
Contributor
Pinging OpenNTPD-portable maintainer: @busterb
Indeed interesting. Any idea why it isn't packaged in Fedora?
IIRC there was a period where it was being maintained only in OpenBSD's tree, but this is no longer the case for almost 2 years now. Perhaps simply nobody picked it up?
|
Pinging OpenNTPD-portable maintainer: @busterb
IIRC there was a period where it was being maintained only in OpenBSD's tree, but this is no longer the case for almost 2 years now. Perhaps simply nobody picked it up? |
rugk commentedSep 29, 2016
An exact time of a device is an important thing for many cryptographic actions (e.g. in TLS/PKI) and therefore the integrity of any time synchronisation should be ensured.
Currently this is AFAIK best possible with tlsdate, a tool, which uses the timestamp send in TLS connections and therefore ensures the integrity of the timestamp one gets.
Preferably this should be used for all VMs.