Re: ntpd: prefer %z when formatting size_t
On Mon, 09 Feb 2015 22:32:55 -0600, Brent Cook wrote: Pretty trivial conversion. ok? OK but size_t should be printed %zu (%zd is ssize_t). - todd
Re: ntpd: prefer %z when formatting size_t
Obviously not that trivial: The return type of sizeof() is size_t, which
is unsigned, thus the second conversion specification should be %zu.
(The printf manpage notes that the %zd conversion indicates that the
argument is of a signed type equivalent in size to a size_t.).
natano
On Mon, Feb 09, 2015 at 10:32:55PM -0600, Brent Cook wrote:
Pretty trivial conversion. ok?
Index: ntp_msg.c
===
RCS file: /cvs/src/usr.sbin/ntpd/ntp_msg.c,v
retrieving revision 1.20
diff -u -p -u -p -r1.20 ntp_msg.c
--- ntp_msg.c 9 Jan 2015 07:35:37 - 1.20
+++ ntp_msg.c 10 Feb 2015 04:23:03 -
@@ -62,7 +62,7 @@ ntp_sendmsg(int fd, struct sockaddr *sa,
}
if (n != sizeof(*msg)) {
- log_warnx(ntp_sendmsg: only %ld of %ld bytes sent, n,
+ log_warnx(ntp_sendmsg: only %zd of %zd bytes sent, n,
sizeof(*msg));
return (-1);
}
Re: ntpd: be more verbose when logging privsep errors
On Mon, 09 Feb 2015 22:34:20 -0600, Brent Cook wrote: This makes it easier for a sysadmin to diagnose a privilege separation path problem without looking at the source code for why 'stat' failed. OK but when printing stb.st_mode you should AND it with ALLPERMS so you don't print non-user bits. - todd
Re: ntpd: prefer %z when formatting size_t
On Mon, Feb 09, 2015 at 10:32:55PM -0600, Brent Cook wrote: Pretty trivial conversion. ok? Well, if it is size_t, it should be %zu. Joerg
Re: ntpd: prefer %z when formatting size_t
On Feb 10, 2015, at 9:37 AM, Todd C. Miller todd.mil...@courtesan.com wrote: On Mon, 09 Feb 2015 22:32:55 -0600, Brent Cook wrote: Pretty trivial conversion. ok? OK but size_t should be printed %zu (%zd is ssize_t). - todd If I had known I would get so many emails over this, I would have just done %zu in the first place :) I was just trying to keep them the same.
Re: pf congestion handling
I already talked to dlg here, but that obviously cuts you out which isn't good :/ * Alexander Bluhm alexander.bl...@gmx.net [2015-02-10 23:12]: We do not use the pf congestion feature, we have disabled it with an #ifdef. Prefering states over rules means that you cannot login into a congested box. There are cases where this policy makes sense, in our use case it does not. well, you can over the console, and preferring existing states is the right thing to do imo: -(D)DoS-Traffic won't match a state, prefering states means that your legit traffic has a much higher chance -ruleset evaluation is MUCH more expensive than state matching not sure whether your product is the extreme outlier here; if it is then the you have to ifdef it out is perfectly acceptable imo; if it isn't we might need a button (shrug). the fact that nobody asked for a button or the like in a decade makes me tend towards not needed. I can't see cases where different congestion states for each input queue are useful. me neither. things are significantly different now than they were 10+ years ago when bob I chose ipintrq full as trigger. the congestion trick isn't as effective any more as it used to be since the arrival of MCLGETI - which overall is much more effective, and less selective at the same time. the two should cooperate.
Re: Getting in touch
The way to get attention around here is show diffs :) On Tue, Feb 10, 2015 at 12:51 AM, aixtools aixto...@gmail.com wrote: L.S., Trying for a bit over a week to gt a response re: libressl. 1) If you have a established mailing-list for libressl - I did not find it. That of course says something about me - and maybe you are trying to keep people who cannot seek well enough away. I can only hope that you take this as intended - a hint you are hard to find. 2) I have some patches/ideas that could be a step forward to having libressl-portable be buildable/packageable for AIX 5.3 TL7 and up. Looking forward to your reply, regards, Michael Felt (aka @rootvgnet, http://www.rootvg.net)
Re: OK... how dare you both even to not publish patches...
On Tue, Feb 10, 2015 at 5:05 AM, Ted Unangst t...@tedunangst.com wrote: Sebastian's emails don't make it to the list, but in the interest of transparency and not hiding any secrets about OpenBSD's security, I'm forwarding it along as requested. Uff. Another one who forgot to get his meds... Ciao! David Sebastian Rother wrote:
Authenticated TLS contraints in ntpd(8)
Hi! Theo, Henning, and me developed an idea to utilize TLS in some way for authenticated time in ntpd(8). We are not intending to use it as a direct time source, but as a constraint to verify the NTP responses. I came up with an implementation that has been designed to be an optional, non-intrusive feature that is now part of OpenBSD -current. From the ntpd.conf(5) 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. The standardized attempts to add authentication to NTP are a) fairly horrible (ASN.1 etc.) and b) rarely deployed. HTTPS is most widely deployed and provides a reference time in the Date: header. The resolution is not good enough as a time source, only seconds and it does not consider network and I/O delays, but it is good enough to provide bounds that can be used to verify the NTP responses. We only use the time from the HTTPS header, and not the TLS timestamp, as the latter is most possibly randomized in modern SSL/TLS implementations. To test it, you can configure one or more HTTPS URLs or hosts in your ntpd.conf that will be queried upon startup of ntpd. Any HTTPS URL would work and the path is fully optional. The server certificate is currently verified against the CA certificates in /etc/ssl/cert.pem; a self-signed certificate would not work unless you add your own CA to the file. ---snip--- servers pool.ntp.org constraints from https://www.google.com/search?q=openntpd; constraints from www.twitter.com constraint from www.apple.com ---snap--- The feature is still experimental and we're continuing to improve the semantics. But it is already fully functional and ready to be tested. The HTTPS client requests are executed in independent processes that are fully isolated from each other and from the NTP processes - a strict separation protects the daemon from any potential failures in the TLS execution. Related commit: http://marc.info/?l=openbsd-cvsm=142355043928397w=2 Have fun with catching the outliars! Reyk
Re: Getting in touch
On 2015-02-10 9:55 AM, Bob Beck wrote:
The way to get attention around here is show diffs :)
On Tue, Feb 10, 2015 at 12:51 AM, aixtoolsaixto...@gmail.com wrote:
L.S.,
Trying for a bit over a week to gt a response re: libressl.
1) If you have a established mailing-list for libressl - I did not find it.
That of course says something about me - and maybe you are trying to keep
people who cannot seek well enough away. I can only hope that you take this
as intended - a hint you are hard to find.
2) I have some patches/ideas that could be a step forward to having
libressl-portable be buildable/packageable for AIX 5.3 TL7 and up.
Looking forward to your reply,
regards,
Michael Felt
(aka @rootvgnet, http://www.rootvg.net)
Then first the simple diff's :)
diff -ur libressl-2.1.3/configure libressl-2.1.3.save/configure
--- libressl-2.1.3/configure2015-01-21 14:42:11 +
+++ libressl-2.1.3.save/configure 2015-02-08 14:25:22 +
@@ -3049,7 +3049,16 @@
PLATFORM_LDADD='-lnsl -lsocket'
;;
- *) ;;
+ *aix*)
+ HOST_OS=aix
+ CFLAGS=
+ PLATFORM_LDADD='-lpthread'
+
+ ;;
+ *)
+ echo $host_os not found
+ exit
+ ;;
esac
case $host_cpu in
diff -ur libressl-2.1.3/crypto/compat/arc4random.h
libressl-2.1.3.save/crypto/compat/arc4random.h
--- libressl-2.1.3/crypto/compat/arc4random.h 2015-01-21 14:04:57 +
+++ libressl-2.1.3.save/crypto/compat/arc4random.h 2015-02-08
15:16:01 +
@@ -6,6 +6,9 @@
#if defined(__FreeBSD__)
#include arc4random_freebsd.h
+#elif defined(_AIX)
+#include arc4random_aix.h
+
#elif defined(__hpux)
#include arc4random_hpux.h
For arc4random_aix.h I was lazy and just copied arc4random_hpux.h
root@x064:[/data/prj/openbsd/libressl/libressl-2.1.3.save/crypto/compat]diff
arc4random_hpux.h arc4random_aix.h
root@x064:[/data/prj/openbsd/libressl/libressl-2.1.3.save/crypto/compat]ls
-l arc4random_hpux.h arc4random_aix.h
-rw-r--r-- 1 michael felt 2193 Feb 8 15:13 arc4random_aix.h
-rw-r--r-- 1 rootsystem 2193 Jan 21 11:46 arc4random_hpux.h
And the attachments:
root@x064:[/data/prj/openbsd/libressl/libressl-2.1.3.save/crypto/compat]ls
-l *aix.c
-rw-r--r-- 1 michael felt 13110 Feb 9 17:19 getentropy_aix.c
-rw-r--r-- 1 michael felt 2401 Feb 9 17:19 issetugid_aix.c
As I do not understand, in detail, what the pseudo entrophy routines are
doing I am guessing
I made an error, i.e., may be introducing some non-randomness by using
the mod (%) operator on the PURR register counters that run in
nanoseconds. I may have left the size at sizeof(u_long_long_t) while the
'random' part is smaller (so high 0 bits not random).
To link on AIX - to support errlog() -lrts is needed (both non-root/root
can write to errpt for this event). Whether you want to use the syslog_r
addition - especially the part
looking up the process name (depends on /proc, so also potentially
affected by a chroot() environment).
Basically, ideas.
I have not change the makefile in compat to add the *aix.o files into
the archive.
Comments welcome!
Michael
p.s. compiling on AIX 5.3 TL7 - 5300-07-10-0943, using IBM C compiler
V11, on a Power6
/* $OpenBSD: $ */
/*
* Copyright (c) 2015 Michael Felt aixto...@gmail.com
* Copyright (c) 2014 Theo de Raadt dera...@openbsd.org
* Copyright (c) 2014 Bob Beck b...@obtuse.com
*
* Permission to use, copy, modify, and distribute this software for any
* purpose with or without fee is hereby granted, provided that the above
* copyright notice and this permission notice appear in all copies.
*
* THE SOFTWARE IS PROVIDED AS IS AND THE AUTHOR DISCLAIMS ALL WARRANTIES
* WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF
* MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR
* ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
* WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN
* ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF
* OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
*
* Intended to Emulate getentropy(2) as documented at:
* http://www.openbsd.org/cgi-bin/man.cgi/OpenBSD-current/man2/getentropy.2
*/
/*
* -lperfstat is needed for the psuedo entropy data
* -lrst is needed for errlog
* also, cc_r, or equivelent is needed for syslog_r (multi-thread safe
libraries)
*/
#include sys/mman.h
#include sys/resource.h
#include sys/socket.h
#include sys/stat.h
#include sys/statvfs.h
#include sys/timers.h
#include stdio.h
#include fcntl.h
#include signal.h
#include termios.h
#include errno.h
#include openssl/sha.h
#include libperfstat.h
#define REPEAT 5
#define min(a, b) (((a) (b)) ? (a) : (b))
#define HX(a, b) \
do { \
if ((a)) \
HD(errno); \
else \
HD(b); \
} while (0)
Re: Getting in touch
Well.. there are issues with that both if you require libraries, and are not certain how the other stuff works. In short, we have to be a lot more careful than this and we can't depend on external libraries. Ideally, for us to deal with this we'd need an decent AIX running machine with OS and compilers, preferably in Austin Texas - It's something we'd need to spend a little time with to fix up. Is that anything you could assist us with? On Tue, Feb 10, 2015 at 3:00 AM, aixtools aixto...@gmail.com wrote: On 2015-02-10 9:55 AM, Bob Beck wrote: The way to get attention around here is show diffs :) On Tue, Feb 10, 2015 at 12:51 AM, aixtoolsaixto...@gmail.com wrote: L.S., Trying for a bit over a week to gt a response re: libressl. 1) If you have a established mailing-list for libressl - I did not find it. That of course says something about me - and maybe you are trying to keep people who cannot seek well enough away. I can only hope that you take this as intended - a hint you are hard to find. 2) I have some patches/ideas that could be a step forward to having libressl-portable be buildable/packageable for AIX 5.3 TL7 and up. Looking forward to your reply, regards, Michael Felt (aka @rootvgnet, http://www.rootvg.net) Then first the simple diff's :) diff -ur libressl-2.1.3/configure libressl-2.1.3.save/configure --- libressl-2.1.3/configure2015-01-21 14:42:11 + +++ libressl-2.1.3.save/configure 2015-02-08 14:25:22 + @@ -3049,7 +3049,16 @@ PLATFORM_LDADD='-lnsl -lsocket' ;; - *) ;; + *aix*) + HOST_OS=aix + CFLAGS= + PLATFORM_LDADD='-lpthread' + + ;; + *) + echo $host_os not found + exit + ;; esac case $host_cpu in diff -ur libressl-2.1.3/crypto/compat/arc4random.h libressl-2.1.3.save/crypto/compat/arc4random.h --- libressl-2.1.3/crypto/compat/arc4random.h 2015-01-21 14:04:57 + +++ libressl-2.1.3.save/crypto/compat/arc4random.h 2015-02-08 15:16:01 + @@ -6,6 +6,9 @@ #if defined(__FreeBSD__) #include arc4random_freebsd.h +#elif defined(_AIX) +#include arc4random_aix.h + #elif defined(__hpux) #include arc4random_hpux.h For arc4random_aix.h I was lazy and just copied arc4random_hpux.h root@x064:[/data/prj/openbsd/libressl/libressl-2.1.3.save/crypto/compat]diff arc4random_hpux.h arc4random_aix.h root@x064:[/data/prj/openbsd/libressl/libressl-2.1.3.save/crypto/compat]ls -l arc4random_hpux.h arc4random_aix.h -rw-r--r-- 1 michael felt 2193 Feb 8 15:13 arc4random_aix.h -rw-r--r-- 1 rootsystem 2193 Jan 21 11:46 arc4random_hpux.h And the attachments: root@x064:[/data/prj/openbsd/libressl/libressl-2.1.3.save/crypto/compat]ls -l *aix.c -rw-r--r-- 1 michael felt 13110 Feb 9 17:19 getentropy_aix.c -rw-r--r-- 1 michael felt 2401 Feb 9 17:19 issetugid_aix.c As I do not understand, in detail, what the pseudo entrophy routines are doing I am guessing I made an error, i.e., may be introducing some non-randomness by using the mod (%) operator on the PURR register counters that run in nanoseconds. I may have left the size at sizeof(u_long_long_t) while the 'random' part is smaller (so high 0 bits not random). To link on AIX - to support errlog() -lrts is needed (both non-root/root can write to errpt for this event). Whether you want to use the syslog_r addition - especially the part looking up the process name (depends on /proc, so also potentially affected by a chroot() environment). Basically, ideas. I have not change the makefile in compat to add the *aix.o files into the archive. Comments welcome! Michael p.s. compiling on AIX 5.3 TL7 - 5300-07-10-0943, using IBM C compiler V11, on a Power6
Re: Authenticated TLS contraints in ntpd(8)
On Tue, 10 Feb 2015 10:55:53 +0100 Reyk Floeter wrote: The standardized attempts to add authentication to NTP are a) fairly horrible (ASN.1 etc.) and b) rarely deployed. When ntpd acts as a server, could the package signing code be of use with ntpd keys?
Re: Authenticated TLS contraints in ntpd(8)
On 2015/02/10 12:32, Reyk Floeter wrote: Let me share the answer to a question that I got in a private mail: On Tue, Feb 10, 2015 at 10:55:53AM +0100, Reyk Floeter wrote: ---snip--- servers pool.ntp.org constraints from https://www.google.com/search?q=openntpd; Cue google turning on captchas for searches for openntpd ;-)
Re: Authenticated TLS contraints in ntpd(8)
On Tue, 10 Feb 2015 13:03:27 + David Dahlberg wrote: The standardized attempts to add authentication to NTP are a) fairly horrible (ASN.1 etc.) and b) rarely deployed. When ntpd acts as a server, could the package signing code be of use with ntpd keys? How exactly? You cannot use signing for PSK, Private Cert GK as they require peer-to-peer shared secrets. The rest of the autokey protocols do not provide any usable identity checks anyway. Nice read: http://zero-entropy.de/autokey_analysis.pdf The HTTPS-based scheme is at least able to link a rough time constraint to a PKI (which autokey is not even able to do) and it follows the general design approach of OpenNTPd: Being simple and good enough for most use cases. I was meaning just for internal OpenBSD use between ntpds really (you would still need a trusted or checked source with a decent crystal) without resorting to handing axes out, outside the standards meeting with the time_t pdf link enscribed in the handle ;-).
Re: Authenticated TLS contraints in ntpd(8)
On Tue, Feb 10, 2015 at 10:51:12PM -0700, Theo de Raadt wrote: So I gave Reyk some beer, and he did the impossible :-) I sense a pattern here. Reyk
Re: pf congestion handling
On 11 Feb 2015, at 8:12 am, Alexander Bluhm alexander.bl...@gmx.net wrote:
On Tue, Feb 10, 2015 at 04:01:19PM +1000, David Gwynne wrote:
i want to remove the congestion stuff in ifqueue, but i dont want
to remove the pf functionality. my attempt at this below.
I like that you replaced the malloc and timeout with a ticks
comparison as it makes the code simpler. The semantic changes a
bit. If the box was unter high network load without softtimer
interrupts, the old code did not clear the congestion. I don't
know wether that behavior was intentional.
i doubt it was intentional.
We do not use the pf congestion feature, we have disabled it with
an #ifdef. Prefering states over rules means that you cannot login
into a congested box. There are cases where this policy makes
sense, in our use case it does not.
maybe we could create explicit pf rule checks for it:
pass in on port ssh
block in quick congested
pass in on port { http https }
instead of having what is effectively an implicit block in quick congested at
the top of the ruleset.
I can't see cases where different congestion states for each input
queue are useful.
me either.
dlg
Re: Authenticated TLS contraints in ntpd(8)
On Tue, Feb 10, 2015 at 11:19 PM, Reyk Floeter r...@openbsd.org wrote: On Tue, Feb 10, 2015 at 10:51:12PM -0700, Theo de Raadt wrote: So I gave Reyk some beer, and he did the impossible :-) I sense a pattern here. Reyk Not enough samples to be a pattern yet.. You shouldn't worry.. It's too bad supporting IkeV1 in your software is impossible.
Re: Authenticated TLS contraints in ntpd(8)
* Henning Brauer hb-openbsdt...@ml.bsws.de [2015-02-10 13:21]: * Kevin Chadwick ma1l1i...@yahoo.co.uk [2015-02-10 13:14]: On Tue, 10 Feb 2015 10:55:53 +0100 Reyk Floeter wrote: The standardized attempts to add authentication to NTP are a) fairly horrible (ASN.1 etc.) and b) rarely deployed. When ntpd acts as a server, could the package signing code be of use with ntpd keys? getting the signature into the ntp packets in a way that doesn't break compatibility is the challenge. let me elaborate slightly: even if we came up with a überauth mechanism that doesn't suck and doesn't break compat, it wouldn't be of much use unless the servers you sync from support it - one of the pools for most. even if you could completely trust them and whatever model of key distribution, for them to support this, you have to get it standarized. and even if we managed to get it pushed through the standards corpses^Wbodies, it would take ages until it gets deployed, IF it ever gets widely deployed. That's a lot of ifs, I leave the judgement on likeliness to you. constraints from https, however - that works today. -- Henning Brauer, h...@bsws.de, henn...@openbsd.org BS Web Services GmbH, http://bsws.de, Full-Service ISP Secure Hosting, Mail and DNS. Virtual Dedicated Servers, Root to Fully Managed Henning Brauer Consulting, http://henningbrauer.com/
Re: Authenticated TLS contraints in ntpd(8)
* Henning Brauer hb-openbsdt...@ml.bsws.de [2015-02-10 13:21]: * Kevin Chadwick ma1l1i...@yahoo.co.uk [2015-02-10 13:14]: On Tue, 10 Feb 2015 10:55:53 +0100 Reyk Floeter wrote: The standardized attempts to add authentication to NTP are a) fairly horrible (ASN.1 etc.) and b) rarely deployed. When ntpd acts as a server, could the package signing code be of use with ntpd keys? getting the signature into the ntp packets in a way that doesn't break compatibility is the challenge. let me elaborate slightly: even if we came up with a überauth mechanism that doesn't suck and doesn't break compat, it wouldn't be of much use unless the servers you sync from support it - one of the pools for most. even if you could completely trust them and whatever model of key distribution, for them to support this, you have to get it standarized. and even if we managed to get it pushed through the standards corpses^Wbodies, it would take ages until it gets deployed, IF it ever gets widely deployed. That's a lot of ifs, I leave the judgement on likeliness to you. constraints from https, however - that works today. So full disclosure, this was my idea, though Reyk wrote the code. I was struck by how 2 decades ago there was common practice to use rdate -a, thus using the RFC 868 timed protocol. It is a one-shot, triggering a slide using the kernel adjtime system call. Then ntp showed up, kind of but it was heavy, and it became more common practice to have small machines do rdate -an. Once again, it is a one-shot, triggering a slide using the kernel adjtime system call. Such practice was good enough for most uses. Some people did this in cron. ntp was just too large to compile, too complicated for automatic setup, so it was rarely used back in those days. Some time went by, and more people started using official NTP, but we wavered, not liking the sourc code. Finally openntpd arrived, designed to be light and secure -- enough so we could run it in all circumstances. It contains protection against NTP packet spoofing, but cannot solve the NTP protocol MITM problems. Recently, tlsdate showed up, which is basically rdate -TLS, and perhaps it has an option like -a, but still that would be the one-shot triggering a slide in the kernel. Solving nothing new really in terms of time quality... However it struck me that we could use such a method to authenticate information learned from NTP sources. As long as the information was handled correctly in one daemon. Asyncronously, and very carefully, using the privsep model for safety. So I gave Reyk some beer, and he did the impossible :-)
Re: pf congestion handling
On Tue, Feb 10, 2015 at 04:01:19PM +1000, David Gwynne wrote: i want to remove the congestion stuff in ifqueue, but i dont want to remove the pf functionality. my attempt at this below. I like that you replaced the malloc and timeout with a ticks comparison as it makes the code simpler. The semantic changes a bit. If the box was unter high network load without softtimer interrupts, the old code did not clear the congestion. I don't know wether that behavior was intentional. We do not use the pf congestion feature, we have disabled it with an #ifdef. Prefering states over rules means that you cannot login into a congested box. There are cases where this policy makes sense, in our use case it does not. I can't see cases where different congestion states for each input queue are useful. OK bluhm@
Re: ntpd: prefer %z when formatting size_t
Brent Cook wrote: On Feb 10, 2015, at 9:37 AM, Todd C. Miller todd.mil...@courtesan.com wrote: On Mon, 09 Feb 2015 22:32:55 -0600, Brent Cook wrote: Pretty trivial conversion. ok? OK but size_t should be printed %zu (%zd is ssize_t). - todd If I had known I would get so many emails over this, I would have just done %zu in the first place :) I was just trying to keep them the same. I don't think I've ever seen a size_t value in the wild that was: 1) larger than SIZE_MAX / 2 2) not the result of an error Usually, if %zu vs %zd matters, it's because somebody screwed up and you actually are looking at a negative size_t. possible exception: -1 as a sentinel. Either way, it may be desirable to make such numbers look negative.
Re: Authenticated TLS contraints in ntpd(8)
Am Dienstag, den 10.02.2015, 12:35 + schrieb Kevin Chadwick: On Tue, 10 Feb 2015 10:55:53 +0100 Reyk Floeter wrote: The standardized attempts to add authentication to NTP are a) fairly horrible (ASN.1 etc.) and b) rarely deployed. When ntpd acts as a server, could the package signing code be of use with ntpd keys? How exactly? You cannot use signing for PSK, Private Cert GK as they require peer-to-peer shared secrets. The rest of the autokey protocols do not provide any usable identity checks anyway. Nice read: http://zero-entropy.de/autokey_analysis.pdf The HTTPS-based scheme is at least able to link a rough time constraint to a PKI (which autokey is not even able to do) and it follows the general design approach of OpenNTPd: Being simple and good enough for most use cases. -- David Dahlberg Fraunhofer FKIE, Dept. Communication Systems (KOM) | Tel: +49-228-9435-845 Fraunhoferstr. 20, 53343 Wachtberg, Germany| Fax: +49-228-856277
Re: Authenticated TLS contraints in ntpd(8)
* Kevin Chadwick ma1l1i...@yahoo.co.uk [2015-02-10 13:14]: On Tue, 10 Feb 2015 10:55:53 +0100 Reyk Floeter wrote: The standardized attempts to add authentication to NTP are a) fairly horrible (ASN.1 etc.) and b) rarely deployed. When ntpd acts as a server, could the package signing code be of use with ntpd keys? getting the signature into the ntp packets in a way that doesn't break compatibility is the challenge. -- Henning Brauer, h...@bsws.de, henn...@openbsd.org BS Web Services GmbH, http://bsws.de, Full-Service ISP Secure Hosting, Mail and DNS. Virtual Dedicated Servers, Root to Fully Managed Henning Brauer Consulting, http://henningbrauer.com/
Re: ntpd: prefer %z when formatting size_t
Brent Cook wrote: On Feb 10, 2015, at 9:37 AM, Todd C. Miller todd.mil...@courtesan.com wrote: On Mon, 09 Feb 2015 22:32:55 -0600, Brent Cook wrote: Pretty trivial conversion. ok? OK but size_t should be printed %zu (%zd is ssize_t). - todd If I had known I would get so many emails over this, I would have just done %zu in the first place :) I was just trying to keep them the same. I don't think I've ever seen a size_t value in the wild that was: 1) larger than SIZE_MAX / 2 2) not the result of an error Usually, if %zu vs %zd matters, it's because somebody screwed up and you actually are looking at a negative size_t. possible exception: -1 as a sentinel. Either way, it may be desirable to make such numbers look negative. Yeah, I agree. Bugs are more likely to be fixed if people see -1. More people will know where to look.
