Re: SSL structs and testing
On 4/1/19 12:00 AM, Hal Murray via devel wrote: There is some cleanup I've wanted to do in that area anyway. I'll try to get to it tonight. Noted, will wait before stirring it up. Only that it seemed reasonable at the time. I was more interested in getting things working than how to test things after we got it working. That is what I expected. But there is enough I don't understand that I wanted to check. -- /"In the end; what separates a Man, from a Slave? Money? Power? No. A Man Chooses, a Slave Obeys."/ -- Andrew Ryan /"Utopia cannot precede the Utopian. It will exist the moment we are fit to occupy it."/ -- Sophia Lamb ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: SSL structs and testing
> After staring at the code for long enough I see a number of natural cleavage > points for solving this issue. MR in a few days. There is some cleanup I've wanted to do in that area anyway. I'll try to get to it tonight. > Is there any particular reason why SSL structs need to be passed all over > the place to functions that do not depend on SSL itself? Only that it seemed reasonable at the time. I was more interested in getting things working than how to test things after we got it working. -- These are my opinions. I hate spam. ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: SSL structs and testing
After staring at the code for long enough I see a number of natural cleavage points for solving this issue. MR in a few days. On 3/31/19 2:33 PM, Ian Bruene wrote: Is there any particular reason why SSL structs need to be passed all over the place to functions that do not depend on SSL itself? The notable example here is nts_ke_do_recieve, which only uses the SSL to pass to SSL_read. I don't see any obvious reason that couldn't be done in the calling function and then pass the buffer instead as the logic doesn't depend on SSL, but on the buffer. As it is now, writing tests for many of the most important functions in the nts codebase is difficult at best because they require setting up SSL, which means faking a connection, which is already awkward and verbose in languages that make for easy shimming, let alone C. -- /"In the end; what separates a Man, from a Slave? Money? Power? No. A Man Chooses, a Slave Obeys."/ -- Andrew Ryan /"Utopia cannot precede the Utopian. It will exist the moment we are fit to occupy it."/ -- Sophia Lamb -- /"In the end; what separates a Man, from a Slave? Money? Power? No. A Man Chooses, a Slave Obeys."/ -- Andrew Ryan /"Utopia cannot precede the Utopian. It will exist the moment we are fit to occupy it."/ -- Sophia Lamb ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: Cert pinning
Let me try this again, as one standalone post, updated with the latest information, including that we already have a documented "ca" option which just needs implementation. 1) I agree that "noval" is useful for _debugging_. For now, and probably indefinitely, it should stay. 2) Since "noval" disables the security, using "noval" means one is essentially falling back to non-NTS. Therefore, "noval" doesn't make any sense for long-term production use. A user contemplating using "noval" indefinitely in production should either fix the validation so NTS is actually providing some security benefit, or just use plain NTP if they don't care about the security benefits of NTS. 3) Right now, you (Gary) are trying to connect to some server, which is failing because it uses a private root CA, which you are (quite reasonably) unwilling to trust system-wide. Once the "ca" option is implemented, you can use that option for that particular association, and you will no longer need "noval" for that particular association. 4) Implementing certificate pinning would be a "nice to have" feature that can increase security above and beyond normal certificate validation. 4A) The pins could come from manual configuration and/or DANE, depending on what someone is willing to implement in ntpd. Those somewhat cover different use cases. Manual configuration allows the administrator of the client to manually tighten the requirements. DANE allows the server operator to request (via DNS records) that clients automatically tighten the requirements. There is overlap where the client and server administrators are the same person, in which case either option may meet their needs (if DNSSEC is available so DANE works securely). 4B) If ntpd implements pinning, it should be in addition to the usual certificate validation, not instead of. This may be controversial with others. Let me explain my thoughts, so we can determine if/where the disagreement lies: - If validation is succeeding, there is no problem. - If validation is failing due to a private root, add it system wide or use the "ca" option to fix the validation. - If validation is failing because the hostname doesn't match, something is configured wrong on either the server or client. Fix that. - If validation is failing because the chain is broken, fix that on the server. - If validation is failing due to legitimate time issues, fix that on the server or with the CA (which is presumably private, because a public CA certainly should have their clocks set correctly). - If validation is failing due to bootstrapping time issues, that's a separate discussion we've already covered, expanding on the guidance from the NTS draft. That affects servers with certificates from public CAs, too. This is probably the most controversial one: - If the server has a self-signed certificate, they should switch to either a certificate from a public CA (e.g. Let's Encrypt) or setup a private CA. In a world where "real" certificates are readily and freely available, I see no reason that security-minded folks (who are doing extra work to opt-in to NTS!) can't use a real certificate or setup a private CA. Am I missing other scenarios where validation fails? If so, please be specific. -- Richard signature.asc Description: OpenPGP digital signature ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: Cert pinning
Yo Richard! On Sun, 31 Mar 2019 21:06:25 -0500 Richard Laager via devel wrote: > On 3/31/19 8:58 PM, Gary E. Miller via devel wrote: > > Yo Richard! > > > > On Sun, 31 Mar 2019 18:47:35 -0500 > > Richard Laager via devel wrote: > > > >> This option would allow Gary's scenario to validate, without > >> needing to trust that root system-wide. He would presumably then > >> eliminate "noval" from that configuration line. > > > > Failing to match a root CA in the local cert is only one of many > > ways that a cert can fail to validate. Before noval can be removed > > there must be a workaround for all of them. > > I don't know how I can be more clear about this. I'm suggesting that > you, individually, would remove "noval" from one particular NTS > association once we have "root" or "ca" to fix validation in that > scenario. I am not suggesting the "noval" option be removed from ntpd. If wishes were dreams then beggars would ride. We may, or may not, ever have the "root" or "ca" options per server. Personally, I find them more confusing than helpful. RGDS GARY --- Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703 g...@rellim.com Tel:+1 541 382 8588 Veritas liberabit vos. -- Quid est veritas? "If you can’t measure it, you can’t improve it." - Lord Kelvin pgppbCrLRBDgW.pgp Description: OpenPGP digital signature ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: Cert pinning
Yo Richard! On Sun, 31 Mar 2019 18:33:54 -0500 Richard Laager via devel wrote: > On 3/28/19 6:06 PM, Gary E. Miller via devel wrote: > > On Thu, 28 Mar 2019 17:54:04 -0500 > > Richard Laager via devel wrote: > > > Updating the pins every 90 days > > was a PITA. > Yes, pinning the end certificate or end public key is going to be > annoying if those rotate frequently. That's why you probably want to > pin the intermediate or root CA public key. Or to one of the public keys in the chain. These are all DANE options. > >> So > >> either pinning needs to override validation, or you'll still need > >> to continue to specify "noval". > > > > Uh, no. > > I'm not sure what you're disagreeing with. In your case, validation is > currently failing for one NTS association, and you have suggested > pinning as a possible solution. Yes, suggested, and shown prior art, and code, to do so. > The quoted text from me above is only claiming that one of the > following must be true: > A) Pinning overrides validation. This allows you to remove "noval" > from this association when you add the pin. > B) Pinning does not override validation. You would still need "noval" >even with the pin. Which ignores all the other ways a cert can fail: before date, after date, hostname mismatch, etc. We need to be able to override all of them at some pint. > > Pinning does not necessarily override validation, it is another > > type of validation. Just as the pinning in the ntpsec.org records > > add to, but does not replace, other validation. > > Right, that's the latter option, so we're on the same page. In that > case, normal validation is still going to fail for you, so you'd have > to keep using "noval". Or, you'd need to add that root for that > association, as discussed below. I was deliberately vague there, so we can't be on the same page. > >> That's all fine. The only tricky thing is that if you pin something > >> other than the end public key (i.e. you pin the intermediate or > >> root CA), then we _do_ need to validate the chain up to that point > >> (albeit maybe still ignoring the NotBefore/NotAfter times). > > > > Uh, no. Just as easy to pin to the end cert. No need to go up. > > But then you need to adjust your pin every 60-90 days when the > certificate changes. As you noted above, this is a pain. Still, you're > welcome to do that. Sigh, we went over this before. You can pin to the root CA, one of the chain CAs, or the final cert. Ditto you can pin to the public key of any, or all, of these. As Matt Salksy mentioned in this thread earlier, he pins the ntpsec.org DANE to the chain cert which only changes every 5 years or so. > But unless ntpd's pinning implementation _only_ allows pinning the end > certificate or public key, then it is possible that someone could pin > an intermediate. Yes, that is a good thing, to be encouraged, for the reasons stated above. > And if someone does that, we either need to disallow > the combination of pinning and "noval" or, if they specify "noval", > we need to do enough validation to verify the pin. Many other options. So I'll not swing at that straw man. > In other words, > imagine that you pin the intermediate CA public key and specify > "noval". We need to verify that the end certificate corresponds to > the server's key Say what? You just said pin to the intermediate cert, not to the any key. How did the key get in here? > and has a valid signature corresponding to the > pinned intermediate CA's public key. That is how we know the pin has > matched. You just moved from pinning to a cert to pinning to a key. Does not compute. > If someone pins the root CA's public key and uses "noval", we would > need to validate the chain another step further, up to the root. Yes, that is how root certs work. You also need to validate the not before date, not after date and FQDN. Stop trying to make this simple. DANE is a long RFC for good reasons. > >> An alternative approach to meet this particular demand would be to > >> allow specifying a root certificate per NTS association. > > > > Gee, I think that is called pinning. DANE type 1. > > I proposed specifying a root certificate for the association, which is > _not_ the same as pinning. Agreed. Hal already said that was on his long term todo list, so that is a distraction here... > Specifying a root certificate for this particular association would > make normal validation pass, which is currently failing (for lack of > that root certificate being in your trusted root certificate list). > This would allow you to remove noval. For this one case, at one point in time. I was using noval to connect to this host long before I was told I could get a copy of the cert. Other participants in the hackathin were on the private IETF LAN, and thus could not get an FQDN, so they needed noval as well. > In other words, these would all pass: > server ... nts noval > server ... nts noval
Re: Cert pinning
On 3/31/19 8:58 PM, Gary E. Miller via devel wrote: > Yo Richard! > > On Sun, 31 Mar 2019 18:47:35 -0500 > Richard Laager via devel wrote: > >> This option would allow Gary's scenario to validate, without needing >> to trust that root system-wide. He would presumably then eliminate >> "noval" from that configuration line. > > Failing to match a root CA in the local cert is only one of many ways > that a cert can fail to validate. Before noval can be removed there > must be a workaround for all of them. I don't know how I can be more clear about this. I'm suggesting that you, individually, would remove "noval" from one particular NTS association once we have "root" or "ca" to fix validation in that scenario. I am not suggesting the "noval" option be removed from ntpd. -- Richard signature.asc Description: OpenPGP digital signature ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: Cert pinning
Yo Richard! On Sun, 31 Mar 2019 18:47:35 -0500 Richard Laager via devel wrote: > This option would allow Gary's scenario to validate, without needing > to trust that root system-wide. He would presumably then eliminate > "noval" from that configuration line. Failing to match a root CA in the local cert is only one of many ways that a cert can fail to validate. Before noval can be removed there must be a workaround for all of them. There are also checks for validity dates, certificate revocation, hostname matching, etc. > 2) If we want more, implement some form of pinning. As the intention > of pinning is to further restrict the trust anchors, this would be in > addition to normal validation, not instead of it. Why? Many other protocols use pinning sometimes to suplement a cert chain, sometimes in addition to it. No reason not to support both options. > The pinning options > would be mutually exclusive of "noval" to keep the implementation > straightforward and to help prevent people from shooting themselves in > the foot. We should be so lucky... RGDS GARY --- Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703 g...@rellim.com Tel:+1 541 382 8588 Veritas liberabit vos. -- Quid est veritas? "If you can’t measure it, you can’t improve it." - Lord Kelvin pgpXkf3cRtqnB.pgp Description: OpenPGP digital signature ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: Cert pinning
On Sun, Mar 31, 2019, 4:47 PM Richard Laager via devel wrote: > On 3/31/19 5:07 AM, Achim Gratz via devel wrote: > > So yes, injecting the trust anchor(s) to use for a specific set of > > NTS-KE would be the easier option. > > How about this: > > 1) Add a root=file (or dir?) option. This overrides the allowed roots > for that association. Only the root(s) in that file are allowed for that > association, regardless of what is normally on the system. So this can > be used to restrict (sort of like pinning, but only for roots), but > assuming we implement pinning, it would be mainly intended to allow a > particular root that is not trusted generally. > > This option would allow Gary's scenario to validate, without needing to > trust that root system-wide. He would presumably then eliminate "noval" > from that configuration line. > According to the ntp.conf man page there already is a ca option (unimplemented) for that. I did not remember seeing that detail earlier. > ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: Cert pinning
On 3/31/19 5:07 AM, Achim Gratz via devel wrote: > So yes, injecting the trust anchor(s) to use for a specific set of > NTS-KE would be the easier option. How about this: 1) Add a root=file (or dir?) option. This overrides the allowed roots for that association. Only the root(s) in that file are allowed for that association, regardless of what is normally on the system. So this can be used to restrict (sort of like pinning, but only for roots), but assuming we implement pinning, it would be mainly intended to allow a particular root that is not trusted generally. This option would allow Gary's scenario to validate, without needing to trust that root system-wide. He would presumably then eliminate "noval" from that configuration line. 2) If we want more, implement some form of pinning. As the intention of pinning is to further restrict the trust anchors, this would be in addition to normal validation, not instead of it. The pinning options would be mutually exclusive of "noval" to keep the implementation straightforward and to help prevent people from shooting themselves in the foot. -- Richard ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Cert pinning
On 3/28/19 6:06 PM, Gary E. Miller via devel wrote: > On Thu, 28 Mar 2019 17:54:04 -0500 > Richard Laager via devel wrote: > Updating the pins every 90 days > was a PITA. Yes, pinning the end certificate or end public key is going to be annoying if those rotate frequently. That's why you probably want to pin the intermediate or root CA public key. >> So >> either pinning needs to override validation, or you'll still need to >> continue to specify "noval". > > Uh, no. I'm not sure what you're disagreeing with. In your case, validation is currently failing for one NTS association, and you have suggested pinning as a possible solution. The quoted text from me above is only claiming that one of the following must be true: A) Pinning overrides validation. This allows you to remove "noval" from this association when you add the pin. B) Pinning does not override validation. You would still need "noval" even with the pin. > Pinning does not necessarily override validation, it is another > type of validation. Just as the pinning in the ntpsec.org records add > to, but does not replace, other validation. Right, that's the latter option, so we're on the same page. In that case, normal validation is still going to fail for you, so you'd have to keep using "noval". Or, you'd need to add that root for that association, as discussed below. >> That's all fine. The only tricky thing is that if you pin something >> other than the end public key (i.e. you pin the intermediate or root >> CA), then we _do_ need to validate the chain up to that point (albeit >> maybe still ignoring the NotBefore/NotAfter times). > > Uh, no. Just as easy to pin to the end cert. No need to go up. But then you need to adjust your pin every 60-90 days when the certificate changes. As you noted above, this is a pain. Still, you're welcome to do that. But unless ntpd's pinning implementation _only_ allows pinning the end certificate or public key, then it is possible that someone could pin an intermediate. And if someone does that, we either need to disallow the combination of pinning and "noval" or, if they specify "noval", we need to do enough validation to verify the pin. In other words, imagine that you pin the intermediate CA public key and specify "noval". We need to verify that the end certificate corresponds to the server's key and has a valid signature corresponding to the pinned intermediate CA's public key. That is how we know the pin has matched. If someone pins the root CA's public key and uses "noval", we would need to validate the chain another step further, up to the root. >> An alternative approach to meet this particular demand would be to >> allow specifying a root certificate per NTS association. > > Gee, I think that is called pinning. DANE type 1. I proposed specifying a root certificate for the association, which is _not_ the same as pinning. Specifying a root certificate for this particular association would make normal validation pass, which is currently failing (for lack of that root certificate being in your trusted root certificate list). This would allow you to remove noval. In other words, these would all pass: server ... nts noval server ... nts noval pin=THE_ROOT_PUBLIC_KEY_HASH server ... nts root=/path/to/this/root.pem while this would fail (because the root still isn't trusted): server ... nts pin=THE_ROOT_PUBLIC_KEY_HASH >> The >> advantage of this approach would be that you can remove "noval" and >> thus get the usual validation, including checking certificate >> NotBefore/NotAfter times. > > Ugh, please no. Pinning is an alternative to noval, not a replacement. I was saying you would "remove noval from the configuration line for that NTS server", not "remove the noval option from ntpd entirely". -- Richard ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: frequency tolerance: 500
> HPET should be OK, but if you can figure out why the TSC doesn't work that > would be better. Check what clocksources are available, there might actually > multiple TSC to chose from. If I was going to chase this, I'd look at the kernel sources to see what changed. I haven't seen similar problems, but I don't have any gear with AMD chips. -- These are my opinions. I hate spam. ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
SSL structs and testing
Is there any particular reason why SSL structs need to be passed all over the place to functions that do not depend on SSL itself? The notable example here is nts_ke_do_recieve, which only uses the SSL to pass to SSL_read. I don't see any obvious reason that couldn't be done in the calling function and then pass the buffer instead as the logic doesn't depend on SSL, but on the buffer. As it is now, writing tests for many of the most important functions in the nts codebase is difficult at best because they require setting up SSL, which means faking a connection, which is already awkward and verbose in languages that make for easy shimming, let alone C. -- /"In the end; what separates a Man, from a Slave? Money? Power? No. A Man Chooses, a Slave Obeys."/ -- Andrew Ryan /"Utopia cannot precede the Utopian. It will exist the moment we are fit to occupy it."/ -- Sophia Lamb ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: frequency tolerance: 500
Udo van den Heuvel via devel writes: >> Again no direct experience, but TSC should be stable these days unless >> something is very much wrong with the drivers. ALso, I've seen reports >> that Ryzen TSC is unstable when certain overclocking options are >> activated. > > I am not overclocking this CPU. The TSC on Ryzen works with the nominal frequency. On certain systems that frequency is modulated, but the kernel doesn't know that until it's controlling those changes. So, while this can be used for overclocking, you can still suffer from this even when you don't overclock (or think you don't do it, but the BIOS decides it's going to switch on the "performance" preset anyway). > Why would tsc be better? Already answered in my other mail. >> Check what clocksources are available, there >> might actually multiple TSC to chose from. > > # cat /sys/devices/system/clocksource/clocksource0/available_clocksource > tsc hpet acpi_pm OK, so only one TSC. Try one of the Linux kernel mailing lists to see if there's something known about this. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ SD adaptation for Waldorf rackAttack V1.04R1: http://Synth.Stromeko.net/Downloads.html#WaldorfSDada ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: frequency tolerance: 500
Udo van den Heuvel via devel writes: > udev. So, with ldattach? > rc.local Use an udev rule again, much easier and more reliable, too. >> I haven't seen one of these in person, but I believe the serial port >> for Ryzen systems is part of the SuperIO, not the chipset itself. > > We have an RS232 PCIe card. Thanks again for not mentioning which actual model. > ASRock QC5000M-ITX/PH with same gps connected very similarly. > Just not on an RS232 card but one of the serial ports of the ITX. …which ties directly into the chipset and hence has very low latency into the interrupt system. >> versions is responsible). I suspect you've been relying on some >> defaults which have changed, but that's just a guess. > > Sounds reasonable given that the situation is currently normalising > after switchign the clocksource to hpet. (from tsc) You should still figure out why TSC is not working correctly. HPET is seriously slow on any modern system and Spectre/Meltdown mitigations have only added to that. > 4800 works very well when you set it up like this: > $PGRMO,,2*75 > $PGRMO,GPRMC,1*3D > $PGRMO,GPGGA,1*20 > $PGRMC,A,42.9,100,,A,3,1,2,9,30*61 That doesn't tell me anything, I don't have that unit or something else using the same command set. But again, you really only want a single message from the GPS since ntpd doesn't look at anything but the first. And since it times with the end of the message, configuring messages that have wildly different sizes is another no-no. PPS will hide that as long as it's available. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ SD adaptations for Waldorf Q V3.00R3 and Q+ V3.54R2: http://Synth.Stromeko.net/Downloads.html#WaldorfSDada ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: frequency tolerance: 500
On 31-03-19 15:13, Achim Gratz via devel wrote: > Udo van den Heuvel via devel writes: >> But it was runnning on clocksource tsc. > > Again no direct experience, but TSC should be stable these days unless > something is very much wrong with the drivers. ALso, I've seen reports > that Ryzen TSC is unstable when certain overclocking options are > activated. I am not overclocking this CPU. > >> We manually switched to hpet and things started stabilising slowly. > > HPET should be OK, but if you can figure out why the TSC doesn't work > that would be better. Why would tsc be better? > Check what clocksources are available, there > might actually multiple TSC to chose from. # cat /sys/devices/system/clocksource/clocksource0/available_clocksource tsc hpet acpi_pm # Udo ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: frequency tolerance: 500
Udo van den Heuvel via devel writes: > But it was runnning on clocksource tsc. Again no direct experience, but TSC should be stable these days unless something is very much wrong with the drivers. ALso, I've seen reports that Ryzen TSC is unstable when certain overclocking options are activated. > We manually switched to hpet and things started stabilising slowly. HPET should be OK, but if you can figure out why the TSC doesn't work that would be better. Check what clocksources are available, there might actually multiple TSC to chose from. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ DIY Stuff: http://Synth.Stromeko.net/DIY.html ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: frequency tolerance: 500
On 31-03-19 14:43, Achim Gratz via devel wrote: >> Same as it ever was: > > How are we supposed to know that if you don't say it? Because I was happy and documented stuff on linuxpps.org. Because no backups were made there the documentation went missing. >> Garmin GPS18X getting power from USB, PPS is coming in on DCD I believe. > > So is this a USB serial or is it an LVC model and you use a "true" > RS232C port? Pover is from USB. The rest is over RS232. Yes, we use an LVC model. > How do you create the necessary PPS device? udev. If you use a > serial device, have you set it to low_latency? rc.local > I haven't seen one of > these in person, but I believe the serial port for Ryzen systems is part > of the SuperIO, not the chipset itself. We have an RS232 PCIe card. >> When I switch the GPSses (I have two) the GPS works fine in the other >> box. So something on this box is hosed and I ruled out wiring, I guess. >> I reset the GPS configuration, I changed PPS pulse length, etc. > > What's that second system you talk about that seems to work? The firewall. ASRock QC5000M-ITX/PH with same gps connected very similarly. Just not on an RS232 card but one of the serial ports of the ITX. > versions is responsible). I suspect you've been relying on some > defaults which have changed, but that's just a guess. Sounds reasonable given that the situation is currently normalising after switchign the clocksource to hpet. (from tsc) >> refclock nmea unit 0 mode 7 flag3 0 flag2 0 flag1 1 time1 0.0006 time2 >> 0.260 baud 4800 > > If you left the default message configuration on, then 4800 baud is way > too slow. 4800 works very well when you set it up like this: $PGRMO,,2*75 $PGRMO,GPRMC,1*3D $PGRMO,GPGGA,1*20 $PGRMC,A,42.9,100,,A,3,1,2,9,30*61 Kind regards, Udo ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: frequency tolerance: 500
Udo van den Heuvel via devel writes: >> How is the GPS connected and how do you get the PPS in? > > Same as it ever was: How are we supposed to know that if you don't say it? > Garmin GPS18X getting power from USB, PPS is coming in on DCD I believe. So is this a USB serial or is it an LVC model and you use a "true" RS232C port? How do you create the necessary PPS device? If you use a serial device, have you set it to low_latency? I haven't seen one of these in person, but I believe the serial port for Ryzen systems is part of the SuperIO, not the chipset itself. There might be some BIOS settings you need to tweak to get optimal performance. > When I switch the GPSses (I have two) the GPS works fine in the other > box. So something on this box is hosed and I ruled out wiring, I guess. > I reset the GPS configuration, I changed PPS pulse length, etc. What's that second system you talk about that seems to work? > And I did not change anythign when this started, I simply rebooted into > a different kernel. Well, forget about the kernel for a moment unless you can actually name the exact version transition that broke things for you (in which case you would need to figure out which of the changes between those two versions is responsible). I suspect you've been relying on some defaults which have changed, but that's just a guess. > refclock nmea unit 0 mode 7 flag3 0 flag2 0 flag1 1 time1 0.0006 time2 > 0.260 baud 4800 If you left the default message configuration on, then 4800 baud is way too slow. I don't think that particular model has any problems with the highest configurable baud rate (should be 38400 I think). Also, just configure the one message you want ntpd to accept (most likely $GPRMC as the Garmin doesn't have $GPZDA) and tell ntpd to only use that (mode 1 or, if you increased the baudrate to 38.4k, mode 49). Reading multiple messages into ntpd is useless, it only ever looks at the first one anyway. Your time1 configuration corresponds to 60ns, so it is almost certainly useless at this point. I would expect around 500µs to 1ms for this parameter. The time2 value is likely way too low for your current setup, but could be correct for a higher baudrate. Last but not least if you get the PPS in via a serial line, you need to configure ntpd to look for the "clear" edge (flag2 1). If you are unsure, install the pps-utils package or whatever your distribution calls it and use ppstest to see which edge is closer to the second. Play around with the PPS width to see if it moves in the right direction to be sure. Now, sometimes the clear edge has a lot more jitter than assert if the hardware has to poll for that edge instead of using interrupts. If so, you can try to reduce the PPS pulse width to the minimum that still registers correctly, switch to the other edge and then adjust the time1 value by the PPS pulse width. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ SD adaptation for Waldorf rackAttack V1.04R1: http://Synth.Stromeko.net/Downloads.html#WaldorfSDada ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: frequency tolerance: 500
On 31-03-19 13:37, Udo van den Heuvel via devel wrote: >> As long as the time is that much off, yes it'll do that. > > Time is not that much off. > It also happens when I sync the clock manually and then start ntpd. > >> Does anything in the boot log complain about unstable clock sources and >> or switching between different ones? > > It switches only during bootup. > Nothing unstable (?) to be seen. But it was runnning on clocksource tsc. We manually switched to hpet and things started stabilising slowly. Udo ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: frequency tolerance: 500
On 31-03-19 13:16, Achim Gratz via devel wrote: >> 186 is not sensible. >> When I set it to 0.000 it still goes way up. > > As long as the time is that much off, yes it'll do that. Time is not that much off. It also happens when I sync the clock manually and then start ntpd. > Does anything in the boot log complain about unstable clock sources and > or switching between different ones? It switches only during bootup. Nothing unstable (?) to be seen. > How is the GPS connected and how do you get the PPS in? Same as it ever was: Garmin GPS18X getting power from USB, PPS is coming in on DCD I believe. >> Or we get this absurd PLL frequency. (4.19.23). > > Same thing most likely. Same thing as what? >> Of course this might just be timing, depending on how soon after bootup, >> at what spot in the PPS cycle ntpd came online. > > No. It's a problem with how you set up your GPS. It's registers with a > too large offset. When I switch the GPSses (I have two) the GPS works fine in the other box. So something on this box is hosed and I ruled out wiring, I guess. I reset the GPS configuration, I changed PPS pulse length, etc. And I did not change anythign when this started, I simply rebooted into a different kernel. >> But I am not yet convinced of that. >> Restarting leads to same results. > > Yes, as long as you don't correct the setup What is not correct? > over and over. Care to show your ntp.conf next time? # grep -v ^# /etc/ntp.conf |grep -v ^$ driftfile /var/lib/ntp/drift restrict default nomodify nopeer noquery restrict -6 default nomodify nopeer noquery restrict 127.0.0.1 restrict -6 ::1 restrict 192.168.10.0 mask 255.255.255.0 nomodify refclock nmea unit 0 mode 7 flag3 0 flag2 0 flag1 1 time1 0.0006 time2 0.260 baud 4800 disable monitor server 192.168.10.98 minpoll 4 iburst server fd01:c1a8:a01:2::1 server ntp.xs4all.nl server ntp2.xs4all.nl server ntp0.nl.net server ntp2.nl.net server keetweej.vanheusden.com server ntp.nmi.nl includefile /etc/ntp/crypto/pw keys /etc/ntp/keys statsdir /var/log/ntp/ Not so complex Udo ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: frequency tolerance: 500
Udo van den Heuvel via devel writes: > On 31-03-19 12:34, Achim Gratz via devel wrote: >>> This behaviour is not normal. >> >> Uh, that is reporting from an ntpd that has just started and hasn't > > One that starts counting again after being up for a little while. > >> collected many statistics. So the only way it can get a PLL frequency >> of 186ppm will be if that value is stored in the drift file. Do you >> have one (usually found somewhere in /var/lib/ntp/), does it contain a >> sensible value? > > 186 is not sensible. > When I set it to 0.000 it still goes way up. As long as the time is that much off, yes it'll do that. >> If so, this doesn't seem to be a rasPi, what is it? > > No, x86_64 with AMD Ryzen. Does anything in the boot log complain about unstable clock sources and or switching between different ones? >> Also, just mumbling about "different behaviour" without showing at >> least one difference isn#t really going to get you much help. > > We either get a pps that is ~250ms off (4.19.30 etc) with ntpd going > backa nd forth between the gps and remote clocks. Well, then set the GPS to "noselect" sync the box to some NTP server that has good time and fix up the time1 (without PPS) and time2 (with PPS) values. The time offset reported by ntpq in both cases (w/ and w/o PPS) should be below the reported jitter and close to zero. How is the GPS connected and how do you get the PPS in? > Or we get this absurd PLL frequency. (4.19.23). Same thing most likely. > Of course this might just be timing, depending on how soon after bootup, > at what spot in the PPS cycle ntpd came online. No. It's a problem with how you set up your GPS. It's registers with a too large offset. > But I am not yet convinced of that. > Restarting leads to same results. Yes, as long as you don't correct the setup it's gonna do the same thing over and over. Care to show your ntp.conf next time? Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ SD adaptation for Waldorf microQ V2.22R2: http://Synth.Stromeko.net/Downloads.html#WaldorfSDada ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: frequency tolerance: 500
On 31-03-19 12:34, Achim Gratz via devel wrote: >> This behaviour is not normal. > > Uh, that is reporting from an ntpd that has just started and hasn't One that starts counting again after being up for a little while. > collected many statistics. So the only way it can get a PLL frequency > of 186ppm will be if that value is stored in the drift file. Do you > have one (usually found somewhere in /var/lib/ntp/), does it contain a > sensible value? 186 is not sensible. When I set it to 0.000 it still goes way up. >> is it software? >> >> rebooted again to 4.19.23 which shows different behaviour than 4.19.30 >> and 32. > > What are these version numbers, Linux kernel? Of course. > If so, this doesn't seem > to be a rasPi, what is it? No, x86_64 with AMD Ryzen. > Also, just mumbling about "different > behaviour" without showing at least one difference isn#t really going to > get you much help. We either get a pps that is ~250ms off (4.19.30 etc) with ntpd going backa nd forth between the gps and remote clocks. Or we get this absurd PLL frequency. (4.19.23). Of course this might just be timing, depending on how soon after bootup, at what spot in the PPS cycle ntpd came online. But I am not yet convinced of that. Restarting leads to same results. Udo ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: frequency tolerance: 500
Udo van den Heuvel via devel writes: > When simply rebooting? Again, the normally the clock is either set from RTC and then ntpdate or ntpd with that allowed to step it. > # ntpq -c kerninfo -pn > associd=0 status=0028 leap_none, sync_unspec, 2 events, no_sys_peer, > pll offset:25.623 > pll frequency: 186.259 > maximum error: 0.10146 > estimated error: 0.00972 > kernel status: pll nano > pll time constant: 6 > precision: 1e-06 > frequency tolerance: 500 > pps frequency: 0 > pps stability: 0 > pps jitter:0 > calibration interval 0 > calibration cycles:0 > jitter exceeded: 0 > stability exceeded:0 > calibration errors:0 > remote refid st t when poll > reach delay offset jitter > === > xNMEA(0) .GPS.0 l- 641 > 0. 48.1256 0. > x192.168.10.98 .GPS.1 u 35 643 > 0.2999 27.4933 4.5941 > fd00:c0a8:a00:1::1 .GPS.1 u7 641 > 0.3935 55.0019 0. > 2001:888:0:7::2 193.67.79.2022 u5 641 > 14.9598 60.2632 0. > 2001:888:0:7::22193.67.79.2022 u 60 641 > 15.5002 23.9193 0. > 193.67.79.202 .STEP. 16 u- 1280 > 0. 0. 0.0002 > 193.79.237.14 .STEP. 16 u- 1280 > 0. 0. 0.0002 > 185.31.230.94 .STEP. 16 u- 1280 > 0. 0. 0.0002 > 134.221.205.12 .STEP. 16 u- 1280 > 0. 0. 0.0002 > > > This behaviour is not normal. Uh, that is reporting from an ntpd that has just started and hasn't collected many statistics. So the only way it can get a PLL frequency of 186ppm will be if that value is stored in the drift file. Do you have one (usually found somewhere in /var/lib/ntp/), does it contain a sensible value? > is it software? > > rebooted again to 4.19.23 which shows different behaviour than 4.19.30 > and 32. What are these version numbers, Linux kernel? If so, this doesn't seem to be a rasPi, what is it? Also, just mumbling about "different behaviour" without showing at least one difference isn#t really going to get you much help. So what does your ntp.conf look like, how is the GPS connected, have you actually provided correct time1 (and perhaps time2 if you're using PPS) values for it? Etc.pp. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Factory and User Sound Singles for Waldorf Blofeld: http://Synth.Stromeko.net/Downloads.html#WaldorfSounds ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: Cert pinning
Matthew Selsky via devel writes: > Do you have an example of software the implements pinning as BOTH a > central trust store + a specific pin? Pinning doesn't provide a trust store, it restricts it. > postfix allows the user to specific a trust-anchor file per destination. So a > typical postfix tls policy table (when you need specific TLS policy rules) > might have: > > foo.com secure tafile=/etc/ssl/certs/QuoVadis_Root_CA_2_G3.pem > bar.com secure > > So foo.com is required to match a specific commercial CA and bar.com is > allowed to match any CA in the system trust store. Yes, except that larger servers would probably want to have multiple CA listed. But in general I think giving NTS it's own trust anchors (either generally or per host) is the right way forward. Also scope restrictions (PKIX) should be evaluated. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Waldorf MIDI Implementation & additional documentation: http://Synth.Stromeko.net/Downloads.html#WaldorfDocs ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: Cert pinning
Richard Laager via devel writes: > I think public key (as opposed to certificate) pinning is the common > approach these days. The application simply requires that one of the > public keys in the chain match the pinned public key. The user can > decide if they want to pin the server public key, the intermediate CA, > or the root CA. Normally pinning is provided from the DNS or from the transport protocol to reduces the number of trust anchors that are possibly valid. > That said, we need to think carefully about the intended interactions > between pinning and validation (or lack thereof with noval). Pinning does not relieve you of any validation, it only tells you which validation paths are valid regardless of what trust anchors you have. > I think that you in particular are using pinning to avoid adding the > server operator's private root certificate that you don't trust. That's not what pinning is for and properly implemented it will not work for that. > An alternative approach to meet this particular demand would be to allow > specifying a root certificate per NTS association. Then you could > specify the private root CA for this particular association, without > needing to trust it system-wide, or even ntpd-wide. The advantage of > this approach would be that you can remove "noval" and thus get the > usual validation, including checking certificate NotBefore/NotAfter times. Actually the correct way to implement this is to import the root CA and constrain the scope of its certificates via PKIX stapling to just the subset of purposes that you indeed trust it for. Unfortunately that is not yet implemented by default for most Linux systems, although gnutls will use such constraints if its new enough (and compiled with the requisite option). So yes, injecting the trust anchor(s) to use for a specific set of NTS-KE would be the easier option. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ SD adaptations for Waldorf Q V3.00R3 and Q+ V3.54R2: http://Synth.Stromeko.net/Downloads.html#WaldorfSDada ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: Garbled IPv6 printout
On Sat, Mar 30, 2019 at 08:05:41PM -0700, Hal Murray wrote: > > A sockaddr is not meant to store the address, ... > > But the API wants a sockaddr. >int accept(int sockfd, struct sockaddr *addr, socklen_t *addrlen); > There is no hint in the man page that an IPv6 address won't fit. > > sockaddr ends with > sa_data[14]; POSIX defines it as "char sa_data[]" and that it is variable length. You should really use any of the other compatible sockaddr structs and cast it to a struct sockaddr *. > That's not big enough for an IPv6 address. I assume somebody suggested > making it bigger and/or changing the parameters to accept when IPv6 was > added. It would be interesting to review that discussion. Nobody suggested that sockaddr was ever something that can hold an IPv4 address or UNIX domain socket, it was never designed to hold that. Instead you always had the give the proper type and cast it. A sockaddr_storage was added as part of adding IPv6 support. If you really want to know all kinds of historic information about such things, I suggest you read Stevens' TCP/IP Illustrated. Kurt ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: frequency tolerance: 500
On 31-03-19 11:21, Achim Gratz via devel wrote: > Udo van den Heuvel via devel writes: >>> How close are you to "true" time when you start the ntpd? >> >> Within 100's of ms if not better. > > If you are really that far off when you start ntpd, When simply rebooting? # ntpq -c kerninfo -pn associd=0 status=0028 leap_none, sync_unspec, 2 events, no_sys_peer, pll offset:25.623 pll frequency: 186.259 maximum error: 0.10146 estimated error: 0.00972 kernel status: pll nano pll time constant: 6 precision: 1e-06 frequency tolerance: 500 pps frequency: 0 pps stability: 0 pps jitter:0 calibration interval 0 calibration cycles:0 jitter exceeded: 0 stability exceeded:0 calibration errors:0 remote refid st t when poll reach delay offset jitter === xNMEA(0) .GPS.0 l- 64 1 0. 48.1256 0. x192.168.10.98 .GPS.1 u 35 64 3 0.2999 27.4933 4.5941 fd00:c0a8:a00:1::1 .GPS.1 u7 64 1 0.3935 55.0019 0. 2001:888:0:7::2 193.67.79.2022 u5 64 1 14.9598 60.2632 0. 2001:888:0:7::22193.67.79.2022 u 60 64 1 15.5002 23.9193 0. 193.67.79.202 .STEP. 16 u- 128 0 0. 0. 0.0002 193.79.237.14 .STEP. 16 u- 128 0 0. 0. 0.0002 185.31.230.94 .STEP. 16 u- 128 0 0. 0. 0.0002 134.221.205.12 .STEP. 16 u- 128 0 0. 0. 0.0002 This behaviour is not normal. is it software? rebooted again to 4.19.23 which shows different behaviour than 4.19.30 and 32. Udo ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: frequency tolerance: 500
Udo van den Heuvel via devel writes: >> How close are you to "true" time when you start the ntpd? > > Within 100's of ms if not better. If you are really that far off when you start ntpd, it can very easily peg at the 500ppm mark. That 500ppm limit means the clock will drift no more than 0.5ms/s, so to correct for 100ms you'd need 200s for the correction to take place and then you are still left with finding the correct clock drift, which can easily take another hour after such a large disturbance. That's why ntpd usually steps the clock when it starts up the first time, which should bring it into the low single-digit ms range. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ DIY Stuff: http://Synth.Stromeko.net/DIY.html ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
Re: We need a HOWTO build from git head
Hal Murray via devel writes: > Context is a helpful user who found a bug in the version of our code from his > distro and wants to test a fix but isn't familiar with git or gitlab etc. This is what I do on each new rasPi or TinkerBoard: --8<---cut here---start->8--- git clone https://gitlab.com/NTPsec/ntpsec.git cd ntpsec && sudo ./buildprep echo "1 SHA1" $(base64 /dev/urandom | tr -d '+/=' | head -c 20) | sudo tee /etc/ntp.keys && sudo chmod 600 /etc/ntp.keys && sudo chown ntp:ntp /etc/ntp.keys sudo rm /run/ntp.conf.dhcp /etc/dhcp/dhclient-exit-hooks.d/ntp sudo mkdir -p /var/log/ntpstats && sudo chown ntp.ntp /var/log/ntpstats ./waf configure --refclock=nmea,pps,local,generic,shm --prefix=/usr --enable-early-droproot ./waf build && sudo ./waf install && sudo systemctl restart ntp && watch -n 5 'ntpq -uW92 -c rv -c peers -c "cv &1" -c "cv &2" -c "cv &3" ; cat /sys/devices/virtual/thermal/thermal_zone0/temp' --8<---cut here---end--->8--- Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ SD adaptations for KORG EX-800 and Poly-800MkII V0.9: http://Synth.Stromeko.net/Downloads.html#KorgSDada ___ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
