Re: specify curves via ecdhe statement in httpd.conf
On Saturday 04 February 2017 15:51:02 Andreas Bartelt wrote: > On 02/04/17 05:26, Joel Sing wrote: > > On Wednesday 01 February 2017 15:41:29 Andreas Bartelt wrote: > >> Hello, > >> > >> after reading the LibreSSL accouncement from today, I assumed that > >> specifying ecdhe "auto" in /etc/httpd.conf would enable X25519, P-256 > >> and P-384 on current. > > > > This is correct. > > > >> I've noticed that "auto" enables only curves x25519 and P-256 (which is > >> what I'd want to use - but somehow unexpected with regard to the > >> announcement). > > > > Why do you believe this is the case? > > Tested with a build of today's current: > - httpd started with ecdhe "auto" in /etc/httpd.conf > - then trying to connect via openssl s_client with -groups P-384 option > doesn't negotiate a cipher suite. > > However, specifying -groups P-256 works. I don't know how to specify > x25519 with OpenBSD's openssl s_client (it's not yet listed in openssl > ecparam -list_curves output) but SSL Labs successfully negotiates via > x25519 and P-256 (but not P-384). P-384 doesn't seem to be enabled with > "auto". You can just specify X25519 as a group - it will not appear in `openssl ecparam -list_curves' since it is not a standard EC curve. > Another confusing test result: > - httpd started with ecdhe "secp384r1" (P-384) > - then trying to connect via openssl s_client with -groups P-384 option > also doesn't negotiate a cipher suite! > > However, SSL Labs successfully connects to httpd and confirms support > for secp384r1. > > Can you reproduce this? No, it works correctly for me (OpenBSD -current, amd64). With "tls ecdhe auto": $ for group in X25519 P-256 P-384; do openssl s_client -connect localhost:443 -groups $group &1 | grep 'Server Temp Key:'; done Server Temp Key: ECDH, X25519, 253 bits Server Temp Key: ECDH, P-256, 256 bits Server Temp Key: ECDH, P-384, 384 bits With "tls ecdhe secp384r1": $ for group in X25519 P-256 P-384; do openssl s_client -connect localhost:443 -groups $group &1 | grep 'Server Temp Key:'; done Server Temp Key: ECDH, P-384, 384 bits > >> Diff is attached which clarifies the meaning of "auto" in httpd.conf.5. > > > > There are some documentation improvements that could be used here, however > > the meaning of auto for httpd.conf.5 needs to refer to the meaning of > > "auto" for libtls (currently tls_config_set_ecdhecurve()). Otherwise > > libtls changes and httpd becomes out of date. > > > >> There currently seems to be no way to explicitly specify x25519, or to > >> specify multiple colon separated curves with the ecdhe statement. Would > >> it make sense to change semantics and make the ecdhe statement in > >> httpd.conf consistent with the recent changes to openssl s_client > >> -groups (e.g., to also allow more common names like P-256 instead of > >> prime256v1)? > > > > Yes - tls_config_set_ecdhecurve() needs to change to accept the same colon > > separate list of priority ordered curve names, that SSL_set1_curves_list() > > accepts.
Re: netcat: IPv6 address support for proxy
Klemens Nanni writes:
> On Sun, Feb 05, 2017 at 12:27:19AM +0100, Jeremie Courreges-Anglas wrote:
>>The colons used in IPv6 addresses conflicts with the proxy port
>>specification. Do the right thing for -x ::1:8080, [::1] and
>>[::1]:8080.
> With this patch '-x ::1' is still broken. I think we should either
> require/enforce square brackets for IPv6 addresses or allow all possible
> notations. Otherwise having '-x 127.0.0.1' working but not '-x ::1'
> seems both confusing and broken to me.
-x ::1 is ambiguous, -x 127.0.0.1 isn't. It's just a fact. The
implementation in nc(1) was based on what ftp(1) accepts. I don't
really see the point in writing code to make ftp(1) and nc(1) behave
differently, nor to prevent people from using stuff that works now in
ftp(1).
This being said, the error message from remote_connect isn't very
useful, especially in that case. And the manpage could document square
brackets.
Comments / ok?
Index: nc.1
===
RCS file: /cvs/src/usr.bin/nc/nc.1,v
retrieving revision 1.81
diff -u -p -r1.81 nc.1
--- nc.126 Jan 2017 22:59:55 - 1.81
+++ nc.15 Feb 2017 03:50:47 -
@@ -327,6 +327,9 @@ If
.Ar port
is not specified, the well-known port for the proxy protocol is used (1080
for SOCKS, 3128 for HTTPS).
+An IPv6 address can be specified unambiguously by enclosing
+.Ar proxy_address
+in square brackets.
.It Fl z
Specifies that
.Nm
Index: netcat.c
===
RCS file: /cvs/src/usr.bin/nc/netcat.c,v
retrieving revision 1.172
diff -u -p -r1.172 netcat.c
--- netcat.c5 Feb 2017 01:39:14 - 1.172
+++ netcat.c5 Feb 2017 03:50:48 -
@@ -856,7 +856,8 @@ remote_connect(const char *host, const c
int s = -1, error, on = 1, save_errno;
if ((error = getaddrinfo(host, port, &hints, &res0)))
- errx(1, "getaddrinfo: %s", gai_strerror(error));
+ errx(1, "getaddrinfo for host \"%s\" port %s: %s", host,
+ port ? port : "any", gai_strerror(error));
for (res = res0; res; res = res->ai_next) {
if ((s = socket(res->ai_family, res->ai_socktype |
--
jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF DDCC 0DFA 74AE 1524 E7EE
Re: netcat: IPv6 address support for proxy
On Sun, Feb 05, 2017 at 12:27:19AM +0100, Jeremie Courreges-Anglas wrote: The colons used in IPv6 addresses conflicts with the proxy port specification. Do the right thing for -x ::1:8080, [::1] and [::1]:8080. With this patch '-x ::1' is still broken. I think we should either require/enforce square brackets for IPv6 addresses or allow all possible notations. Otherwise having '-x 127.0.0.1' working but not '-x ::1' seems both confusing and broken to me.
Re: netcat: IPv6 address support for proxy
ok beck@
On Sun, Feb 05, 2017 at 12:27:19AM +0100, Jeremie Courreges-Anglas wrote:
>
> The colons used in IPv6 addresses conflicts with the proxy port
> specification. Do the right thing for -x ::1:8080, [::1] and
> [::1]:8080.
>
> ok?
>
>
> Index: netcat.c
> ===
> RCS file: /d/cvs/src/usr.bin/nc/netcat.c,v
> retrieving revision 1.171
> diff -u -p -p -u -r1.171 netcat.c
> --- netcat.c 30 Nov 2016 07:56:23 - 1.171
> +++ netcat.c 4 Feb 2017 23:24:42 -
> @@ -148,8 +148,8 @@ main(int argc, char *argv[])
> struct servent *sv;
> socklen_t len;
> struct sockaddr_storage cliaddr;
> - char *proxy;
> - const char *errstr, *proxyhost = "", *proxyport = NULL;
> + char *proxy, *proxyport = NULL;
> + const char *errstr;
> struct addrinfo proxyhints;
> char unix_dg_tmp_socket_buf[UNIX_DG_TMP_SOCKET_SIZE];
> struct tls_config *tls_cfg = NULL;
> @@ -426,15 +426,29 @@ main(int argc, char *argv[])
> if (family == AF_UNIX)
> errx(1, "no proxy support for unix sockets");
>
> - /* XXX IPv6 transport to proxy would probably work */
> - if (family == AF_INET6)
> - errx(1, "no proxy support for IPv6");
> -
> if (sflag)
> errx(1, "no proxy support for local source address");
>
> - proxyhost = strsep(&proxy, ":");
> - proxyport = proxy;
> + if (*proxy == '[') {
> + ++proxy;
> + proxyport = strchr(proxy, ']');
> + if (proxyport == NULL)
> + errx(1, "missing closing bracket in proxy");
> + *proxyport++ = '\0';
> + if (*proxyport == '\0')
> + /* Use default proxy port. */
> + proxyport = NULL;
> + else {
> + if (*proxyport == ':')
> + ++proxyport;
> + else
> + errx(1, "garbage proxy port delimiter");
> + }
> + } else {
> + proxyport = strrchr(proxy, ':');
> + if (proxyport != NULL)
> + *proxyport++ = '\0';
> + }
>
> memset(&proxyhints, 0, sizeof(struct addrinfo));
> proxyhints.ai_family = family;
> @@ -617,7 +631,7 @@ main(int argc, char *argv[])
> }
> if (xflag)
> s = socks_connect(host, portlist[i], hints,
> - proxyhost, proxyport, proxyhints, socksv,
> + proxy, proxyport, proxyhints, socksv,
> Pflag);
> else
> s = remote_connect(host, portlist[i], hints);
> --
> jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF DDCC 0DFA 74AE 1524 E7EE
>
netcat: IPv6 address support for proxy
The colons used in IPv6 addresses conflicts with the proxy port
specification. Do the right thing for -x ::1:8080, [::1] and
[::1]:8080.
ok?
Index: netcat.c
===
RCS file: /d/cvs/src/usr.bin/nc/netcat.c,v
retrieving revision 1.171
diff -u -p -p -u -r1.171 netcat.c
--- netcat.c30 Nov 2016 07:56:23 - 1.171
+++ netcat.c4 Feb 2017 23:24:42 -
@@ -148,8 +148,8 @@ main(int argc, char *argv[])
struct servent *sv;
socklen_t len;
struct sockaddr_storage cliaddr;
- char *proxy;
- const char *errstr, *proxyhost = "", *proxyport = NULL;
+ char *proxy, *proxyport = NULL;
+ const char *errstr;
struct addrinfo proxyhints;
char unix_dg_tmp_socket_buf[UNIX_DG_TMP_SOCKET_SIZE];
struct tls_config *tls_cfg = NULL;
@@ -426,15 +426,29 @@ main(int argc, char *argv[])
if (family == AF_UNIX)
errx(1, "no proxy support for unix sockets");
- /* XXX IPv6 transport to proxy would probably work */
- if (family == AF_INET6)
- errx(1, "no proxy support for IPv6");
-
if (sflag)
errx(1, "no proxy support for local source address");
- proxyhost = strsep(&proxy, ":");
- proxyport = proxy;
+ if (*proxy == '[') {
+ ++proxy;
+ proxyport = strchr(proxy, ']');
+ if (proxyport == NULL)
+ errx(1, "missing closing bracket in proxy");
+ *proxyport++ = '\0';
+ if (*proxyport == '\0')
+ /* Use default proxy port. */
+ proxyport = NULL;
+ else {
+ if (*proxyport == ':')
+ ++proxyport;
+ else
+ errx(1, "garbage proxy port delimiter");
+ }
+ } else {
+ proxyport = strrchr(proxy, ':');
+ if (proxyport != NULL)
+ *proxyport++ = '\0';
+ }
memset(&proxyhints, 0, sizeof(struct addrinfo));
proxyhints.ai_family = family;
@@ -617,7 +631,7 @@ main(int argc, char *argv[])
}
if (xflag)
s = socks_connect(host, portlist[i], hints,
- proxyhost, proxyport, proxyhints, socksv,
+ proxy, proxyport, proxyhints, socksv,
Pflag);
else
s = remote_connect(host, portlist[i], hints);
--
jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF DDCC 0DFA 74AE 1524 E7EE
Re: remove AF_UNIX SOCK_RAW "support"
On Sat, 4 Feb 2017, Jason McIntyre wrote: > On Sat, Feb 04, 2017 at 01:22:40PM -0800, Philip Guenther wrote: > > > > It's not specified what AF_UNIX 'raw' sockets mean anyway. FreeBSD and > > i'll repeat my "clueless networker" moniker, but point out that ip(4) > has a section on "Raw IP Sockets". np. ip(4) is about AF_INET; AF_UNIX is described in unix(4)...which has no mention of raw sockets. Indeed, it says: PROTOCOLS The UNIX-domain protocol family is comprised of simple transport protocols that support the SOCK_STREAM, SOCK_SEQPACKET, and SOCK_DGRAM abstractions. <...> So no, it's not currently documented. :-) Philip
Re: remove AF_UNIX SOCK_RAW "support"
Philip Guenther writes: > It's not specified what AF_UNIX 'raw' sockets mean anyway. FreeBSD and > NetBSD have removed this entry in unixsw[], so it's clear it's not being > used in the ecosystem, so let's kill it too. > > ok? ok jca@ -- jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF DDCC 0DFA 74AE 1524 E7EE
Re: remove AF_UNIX SOCK_RAW "support"
On Sat, Feb 04, 2017 at 01:22:40PM -0800, Philip Guenther wrote:
>
> It's not specified what AF_UNIX 'raw' sockets mean anyway. FreeBSD and
i'll repeat my "clueless networker" moniker, but point out that ip(4)
has a section on "Raw IP Sockets".
jmc
> NetBSD have removed this entry in unixsw[], so it's clear it's not being
> used in the ecosystem, so let's kill it too.
>
> ok?
>
> Philip Guenther
>
> Index: kern/uipc_proto.c
> ===
> RCS file: /data/src/openbsd/src/sys/kern/uipc_proto.c,v
> retrieving revision 1.10
> diff -u -p -r1.10 uipc_proto.c
> --- kern/uipc_proto.c 23 Jan 2017 16:31:24 - 1.10
> +++ kern/uipc_proto.c 4 Feb 2017 20:19:28 -
> @@ -64,11 +64,6 @@ struct protosw unixsw[] = {
>uipc_usrreq,
>0, 0, 0, 0,
> },
> -{ 0, 0, 0, 0,
> - 0, 0, 0, 0,
> - raw_usrreq,
> - raw_init, 0, 0, 0,
> -}
> };
>
> struct domain unixdomain =
>
remove AF_UNIX SOCK_RAW "support"
It's not specified what AF_UNIX 'raw' sockets mean anyway. FreeBSD and
NetBSD have removed this entry in unixsw[], so it's clear it's not being
used in the ecosystem, so let's kill it too.
ok?
Philip Guenther
Index: kern/uipc_proto.c
===
RCS file: /data/src/openbsd/src/sys/kern/uipc_proto.c,v
retrieving revision 1.10
diff -u -p -r1.10 uipc_proto.c
--- kern/uipc_proto.c 23 Jan 2017 16:31:24 - 1.10
+++ kern/uipc_proto.c 4 Feb 2017 20:19:28 -
@@ -64,11 +64,6 @@ struct protosw unixsw[] = {
uipc_usrreq,
0, 0, 0, 0,
},
-{ 0, 0, 0, 0,
- 0, 0, 0, 0,
- raw_usrreq,
- raw_init,0, 0, 0,
-}
};
struct domain unixdomain =
Re: dhcpd.conf(5): "domain name" -> "hostname" for next-server option
On Sat, Feb 04, 2017 at 10:12:17PM +0100, Jeremie Courreges-Anglas wrote: > Jason McIntyre writes: > > > On Sat, Feb 04, 2017 at 06:14:35PM +, Andrew Grillet wrote: > >> Hi > >> > >> "a name that can be looked up in the DNS" > >> > >> Please can this phrase be used in the man page -it is a really good > >> explanation. > >> > > > > ...but an awkward phrasing, especially if it's to be repeated in many > > places. it may be simpler to define what we mean, in one place, or use > > something more succint (resolvable address). or wait! what about "hostname"! > > Easy solution: replace (almost) all "domain name" occurrences with > "hostname". > > ok? > well, that's what i was suggesting! i'm not a great judge of networking terminology, but i think this is clear enough. it's ok by me. jmc > > Index: dhcpd.conf.5 > === > RCS file: /d/cvs/src/usr.sbin/dhcpd/dhcpd.conf.5,v > retrieving revision 1.17 > diff -u -p -p -u -r1.17 dhcpd.conf.5 > --- dhcpd.conf.5 11 Jun 2015 12:48:32 - 1.17 > +++ dhcpd.conf.5 4 Feb 2017 21:09:59 - > @@ -219,7 +219,7 @@ option domain-name-servers ns1.isc.org, > .Ed > .Pp > As you can see in Example 2, it's legal to specify host addresses in > -parameters as domain names rather than as numeric IP addresses. > +parameters as hostnames rather than as numeric IP addresses. > If a given hostname resolves to more than one IP address (for example, if > that host has two Ethernet interfaces), both addresses are supplied to > the client. > @@ -246,10 +246,10 @@ So for the first subnet, for example, th > .Dl option routers 204.254.239.1; > .Pp > Note that the address here is specified numerically. > -This is not required \- if you have a different domain name for each > -interface on your router, it's perfectly legitimate to use the domain name > +This is not required \- if you have a different hostname for each > +interface on your router, it's perfectly legitimate to use the hostname > for that interface instead of the numeric address. > -However, in many cases there may be only one domain name for all of a > router's > +However, in many cases there may be only one hostname for all of a router's > IP addresses, and it would not be appropriate to use that name here. > .Pp > In Example 1 there is also a > @@ -358,7 +358,7 @@ client should boot. > should be the name of the shared network. > This name is used when printing debugging messages, so it should be > descriptive for the shared network. > -The name may have the syntax of a valid domain name > +The name may have the syntax of a valid hostname > (although it will never be used as such), or it may be any arbitrary > name, enclosed in quotes. > .Pp > @@ -649,7 +649,7 @@ the server from which the initial boot f > .Ic filename > statement) is to be loaded. > .Ar server-name > -should be a numeric IP address or a domain name. > +should be a numeric IP address or a hostname. > If no > .Ic next-server > parameter applies to a given client, the DHCP server's IP address is used. > @@ -678,7 +678,7 @@ declaration containing that > statement. > Each > .Ar address > -should be either an IP address or a domain name which resolves to one > +should be either an IP address or a hostname which resolves to one > or more IP addresses. > .Pp > Clients with fixed addresses are not assigned DHCP leases, > @@ -753,7 +753,7 @@ The > .Ic get-lease-hostnames > statement is used to tell > .Xr dhcpd 8 > -whether or not to look up the domain name corresponding to the IP address of > +whether or not to look up the hostname corresponding to the IP address of > each address in the lease pool and use that address for the DHCP > .Ic hostname > option. > > -- > jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF DDCC 0DFA 74AE 1524 E7EE >
Re: Update for US Holidays.
On Sat, Feb 04, 2017 at 01:52:14PM -0700, Bob Beck wrote: > > Presented without further comment. > > ok? > Or maybe this is more appropriate: Index: calendar.history === RCS file: /cvs/src/usr.bin/calendar/calendars/calendar.history,v retrieving revision 1.80 diff -u -p -u -p -r1.80 calendar.history --- calendar.history19 Nov 2016 12:41:22 - 1.80 +++ calendar.history4 Feb 2017 21:28:55 - @@ -475,6 +475,7 @@ 12/12 First wireless message sent across Atlantic by Marconi, 1901 12/13 Dartmouth College chartered, 1769 12/14 Portugal joins the United Nations, 1955 +12/14 World totals the cost of running embedded 32 bit Linux, 1901 12/15 Argo Merchant oil spill, 1976 12/15 James Naismith invents basketball, Canada, 1891 12/16 Pokemon episode (Electric Soldier Porygon) triggers attacks of
Re: Update for US Holidays.
On Sat, Feb 04, 2017 at 12:59:53PM -0800, Philip Guenther wrote: > On Sat, Feb 4, 2017 at 12:52 PM, Bob Beck wrote: > > > > Presented without further comment. > > > > ok? > > NACK. Obsolete 32bit time_t OSes can track their own damn holidays. But how will I remember to be appropriately devotional if my embedded linux pacemaker didn't kill me the previous day? :)
Re: dhcpd.conf(5): "domain name" -> "hostname" for next-server option
Jason McIntyre writes: > On Sat, Feb 04, 2017 at 06:14:35PM +, Andrew Grillet wrote: >> Hi >> >> "a name that can be looked up in the DNS" >> >> Please can this phrase be used in the man page -it is a really good >> explanation. >> > > ...but an awkward phrasing, especially if it's to be repeated in many > places. it may be simpler to define what we mean, in one place, or use > something more succint (resolvable address). or wait! what about "hostname"! Easy solution: replace (almost) all "domain name" occurrences with "hostname". ok? Index: dhcpd.conf.5 === RCS file: /d/cvs/src/usr.sbin/dhcpd/dhcpd.conf.5,v retrieving revision 1.17 diff -u -p -p -u -r1.17 dhcpd.conf.5 --- dhcpd.conf.511 Jun 2015 12:48:32 - 1.17 +++ dhcpd.conf.54 Feb 2017 21:09:59 - @@ -219,7 +219,7 @@ option domain-name-servers ns1.isc.org, .Ed .Pp As you can see in Example 2, it's legal to specify host addresses in -parameters as domain names rather than as numeric IP addresses. +parameters as hostnames rather than as numeric IP addresses. If a given hostname resolves to more than one IP address (for example, if that host has two Ethernet interfaces), both addresses are supplied to the client. @@ -246,10 +246,10 @@ So for the first subnet, for example, th .Dl option routers 204.254.239.1; .Pp Note that the address here is specified numerically. -This is not required \- if you have a different domain name for each -interface on your router, it's perfectly legitimate to use the domain name +This is not required \- if you have a different hostname for each +interface on your router, it's perfectly legitimate to use the hostname for that interface instead of the numeric address. -However, in many cases there may be only one domain name for all of a router's +However, in many cases there may be only one hostname for all of a router's IP addresses, and it would not be appropriate to use that name here. .Pp In Example 1 there is also a @@ -358,7 +358,7 @@ client should boot. should be the name of the shared network. This name is used when printing debugging messages, so it should be descriptive for the shared network. -The name may have the syntax of a valid domain name +The name may have the syntax of a valid hostname (although it will never be used as such), or it may be any arbitrary name, enclosed in quotes. .Pp @@ -649,7 +649,7 @@ the server from which the initial boot f .Ic filename statement) is to be loaded. .Ar server-name -should be a numeric IP address or a domain name. +should be a numeric IP address or a hostname. If no .Ic next-server parameter applies to a given client, the DHCP server's IP address is used. @@ -678,7 +678,7 @@ declaration containing that statement. Each .Ar address -should be either an IP address or a domain name which resolves to one +should be either an IP address or a hostname which resolves to one or more IP addresses. .Pp Clients with fixed addresses are not assigned DHCP leases, @@ -753,7 +753,7 @@ The .Ic get-lease-hostnames statement is used to tell .Xr dhcpd 8 -whether or not to look up the domain name corresponding to the IP address of +whether or not to look up the hostname corresponding to the IP address of each address in the lease pool and use that address for the DHCP .Ic hostname option. -- jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF DDCC 0DFA 74AE 1524 E7EE
Re: Update for US Holidays.
On Sat, Feb 4, 2017 at 12:52 PM, Bob Beck wrote: > > Presented without further comment. > > ok? NACK. Obsolete 32bit time_t OSes can track their own damn holidays.
Update for US Holidays.
Presented without further comment. ok? Index: calendar.usholiday === RCS file: /cvs/src/usr.bin/calendar/calendars/calendar.usholiday,v retrieving revision 1.9 diff -u -p -u -p -r1.9 calendar.usholiday --- calendar.usholiday 19 Jan 2015 18:07:47 - 1.9 +++ calendar.usholiday 4 Feb 2017 20:50:41 - @@ -33,6 +33,7 @@ 11/SunFirstDaylight Saving Time ends; clocks move back (1st Sunday in November) 11/11 Veterans' Day 11/ThuFourth Thanksgiving Day (4th Thursday in November) +12/14 "National Day of Patriotic Devotion" (After 1901, for 32 bit time_t systems) 12/21* Winter Solstice 12/24 Christmas Eve 12/25 Christmas
Re: dhcpd.conf(5): "domain name" -> "hostname" for next-server option
On Sat, Feb 04, 2017 at 06:14:35PM +, Andrew Grillet wrote: > Hi > > "a name that can be looked up in the DNS" > > Please can this phrase be used in the man page -it is a really good > explanation. > ...but an awkward phrasing, especially if it's to be repeated in many places. it may be simpler to define what we mean, in one place, or use something more succint (resolvable address). or wait! what about "hostname"! jmc > > > On 4 February 2017 at 15:34, Jeremie Courreges-Anglas > wrote: > > > Theo Buehler writes: > > > > > On Wed, Jan 11, 2017 at 09:30:15PM +0100, Theo Buehler wrote: > > >> The TOK_NEXT_SERVER case in parse_statement() calls > > parse_ip_addr_or_hostname(), > > >> so I think the next-server option wants a host name, not a domain name: > > > > > > Any takers? I previously suggested 'host name', but the rest of the page > > > writes 'hostname', so let's go with that. > > > > "hostname" sounds less misleading indeed, I believe what is really meant > > here is "a name that can be looked up in the DNS". Most occurrences of > > "domain name" in this manpage carry the same intent. Do we want to > > convert those? > > > > FWIW, https://tools.ietf.org/html/rfc7719#section-2 acknowledges the > > fact that "host name" has multiple meanings: is it a FQDN, only the > > first label of an FQDN...? > > > > -- > > jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF DDCC 0DFA 74AE 1524 E7EE > > > >
Re: dhcpd.conf(5): "domain name" -> "hostname" for next-server option
Hi "a name that can be looked up in the DNS" Please can this phrase be used in the man page -it is a really good explanation. On 4 February 2017 at 15:34, Jeremie Courreges-Anglas wrote: > Theo Buehler writes: > > > On Wed, Jan 11, 2017 at 09:30:15PM +0100, Theo Buehler wrote: > >> The TOK_NEXT_SERVER case in parse_statement() calls > parse_ip_addr_or_hostname(), > >> so I think the next-server option wants a host name, not a domain name: > > > > Any takers? I previously suggested 'host name', but the rest of the page > > writes 'hostname', so let's go with that. > > "hostname" sounds less misleading indeed, I believe what is really meant > here is "a name that can be looked up in the DNS". Most occurrences of > "domain name" in this manpage carry the same intent. Do we want to > convert those? > > FWIW, https://tools.ietf.org/html/rfc7719#section-2 acknowledges the > fact that "host name" has multiple meanings: is it a FQDN, only the > first label of an FQDN...? > > -- > jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF DDCC 0DFA 74AE 1524 E7EE > >
Re: "savecore: /dev/sd1b: Device not configured" error on boot, for no valid reason
thread moved from misc@ to tech@ due to a diff. (see http://marc.info/?l=openbsd-bugs&m=148612339714423 for previous messages) On Sat, Feb 04, 2017 at 09:47:04PM +0800, Tinker wrote: > Hi Sebastien and Philip, > > Thanks for your clarifications. It was interesting to learn to know that you > should have a swap drive on the "root disk" (that is on the crypto softraid) > for catching kernel panic coredumps to. > > > I guess my last question on this topic of kernel panic coredump on swap > drive, would be: > > How large should the swap drive be to accomodate any such coredump - the > same size as the physical RAM of the machine, or less, or more? I think it is at least the physical RAM of the machine. crash(8) man page stands for: When the system crashes it writes (or at least attempts to write) an image of memory, including the kernel image, onto the dump device. So physical RAM + some megas for kernel ? > On 2017-02-04 03:17, Philip Guenther wrote: > > On Fri, 3 Feb 2017, Sebastien Marie wrote: > > ... > > > My understanding is if savecore(8) is able to extract bsd.core > > > information from swap partition, it means the bsd.core information is > > > *not* encrypted by crypto-swap (else, as keys are discarded on reboot, > > > savecore(8) wouldn't have any way to uncrypt the swap without keys). > > > So > > > as bsd.core is readable by savecore(8), it means it is also readable > > > by > > > attacker (by direct read of the swap partition - unplug the disk and > > > voila). > > > > Right: if your system crashes and is made to write do "boot crash" then > > the information that was in memory at the time will be written out > > without > > being affected by whether swap encryption is enabled. That's not what > > swap encryption is for. > > So that's what happens when you have "reboot on panic" (sysctl ddb.panic=0) > set, and you get a kernel panic. on panic, the system will not enter in ddb(4). Only a stack trace will be print on console. next, reboot(2) is called with RB_AUTOBOOT | RB_DUMP. RB_AUTOBOOT The default, causing the system to reboot in its usual fashion. RB_DUMP Dump kernel memory before rebooting; see savecore(8) for more information. so a crash dump (bsd.core) is written to dump device. > > If someone can get to ddb they can peel all the information out the > > kernel anyway! > > Sure. > > I guess you not had a particular point here. I think generally it's easier > to steal a harddrive, than to steal access to someone's kernel debugger (in > default OpenBSD configuration [where ddb.panic=1], the only way to get into > the kernel debugger would be if the robber succeeded with keeping the device > powered on, and, somehow induce a kernel panic). > > > Swap encryption is like selecting a TLS cipher suite that uses an > > ephemeral key to get forward security: the goal is to make it so that > > when > > you choose to forget the past, it really is gone and can't be dredged > > up. > > > > Let's imagine that FDE on your box is defeated or evaded: > > - laptop is stolen while you're logged in > > - government locks you up until you decrypt > > - criminals use 'rubber-hose cryptanalysis' > > - actual crypto failure > > > > At that point, they have all your *current* data. What do they see if > > they then look at your swap partition? If you didn't use swap > > encryption > > then they see data from the possibly-distant past; if you used swap > > encryption then they would only see what the currently running system > > could see and *not* anything beyond the immediate past. > > Did you have a point here? I don't see how this relates with whether the > swap has one or two layers of crypto atop it - > > If only one (ordinary swap encryption), then after reboot all old swap is > likely lost - but a kernel panic coredump on the swap would be unencrypted > and stay around on the disk for quite a while. > > If double (ordinary swap encryption + crypto softraid), then after reboot > all old swap is likely lost, and retrieval of panic coredump data (new or > any old) from the crypto softraid-based swap would require the softraid's > crypto key. the swap-crypto layer is useful when the system is used in normal operation (no panic). it ensures between two boots the swap device contains only data from current boot. I agree that panic() introduce a way to put potential sensitive data unencrypted on dump device (the swap partition). The device could be encrypted with crypto-softraid or not. > > > Now, if the swap partition is on crypto-softraid, before accessing the > > > swap layer, an attacker needs the key of crypto-softraid. So bsd.core > > > information is protected from above attack. > > > > Correct, though in that case the attacks above will then also be able to > > see what was on your machine at that past time. Someone paranoid about > > what's in memory on their box and for whom the att
Re: specify curves via ecdhe statement in httpd.conf
On 02/04/17 17:15, Bob Beck wrote: try connecting with openbsd nc rather than s-client with ecdhe "auto" as well as ecdhe "secp384r1" in /etc/httpd.conf, I can successfully negotiate a TLS cipher suite via nc -vvv -c 443 However, nc doesn't give any output with regard to the negotiated curve for ecdhe. On Sat, Feb 4, 2017 at 09:13 Bob Beck wrote: On Sat, Feb 4, 2017 at 07:51 Andreas Bartelt wrote: On 02/04/17 05:26, Joel Sing wrote: On Wednesday 01 February 2017 15:41:29 Andreas Bartelt wrote: Hello, after reading the LibreSSL accouncement from today, I assumed that specifying ecdhe "auto" in /etc/httpd.conf would enable X25519, P-256 and P-384 on current. This is correct. I've noticed that "auto" enables only curves x25519 and P-256 (which is what I'd want to use - but somehow unexpected with regard to the announcement). Why do you believe this is the case? Tested with a build of today's current: - httpd started with ecdhe "auto" in /etc/httpd.conf - then trying to connect via openssl s_client with -groups P-384 option doesn't negotiate a cipher suite. However, specifying -groups P-256 works. I don't know how to specify x25519 with OpenBSD's openssl s_client (it's not yet listed in openssl ecparam -list_curves output) but SSL Labs successfully negotiates via x25519 and P-256 (but not P-384). P-384 doesn't seem to be enabled with "auto". Another confusing test result: - httpd started with ecdhe "secp384r1" (P-384) - then trying to connect via openssl s_client with -groups P-384 option also doesn't negotiate a cipher suite! However, SSL Labs successfully connects to httpd and confirms support for secp384r1. Can you reproduce this? Diff is attached which clarifies the meaning of "auto" in httpd.conf.5. There are some documentation improvements that could be used here, however the meaning of auto for httpd.conf.5 needs to refer to the meaning of "auto" for libtls (currently tls_config_set_ecdhecurve()). Otherwise libtls changes and httpd becomes out of date. There currently seems to be no way to explicitly specify x25519, or to specify multiple colon separated curves with the ecdhe statement. Would it make sense to change semantics and make the ecdhe statement in httpd.conf consistent with the recent changes to openssl s_client -groups (e.g., to also allow more common names like P-256 instead of prime256v1)? Yes - tls_config_set_ecdhecurve() needs to change to accept the same colon separate list of priority ordered curve names, that SSL_set1_curves_list() accepts.
Re: specify curves via ecdhe statement in httpd.conf
try connecting with openbsd nc rather than s-client On Sat, Feb 4, 2017 at 09:13 Bob Beck wrote: > > On Sat, Feb 4, 2017 at 07:51 Andreas Bartelt wrote: > > On 02/04/17 05:26, Joel Sing wrote: > > On Wednesday 01 February 2017 15:41:29 Andreas Bartelt wrote: > >> Hello, > >> > >> after reading the LibreSSL accouncement from today, I assumed that > >> specifying ecdhe "auto" in /etc/httpd.conf would enable X25519, P-256 > >> and P-384 on current. > > > > This is correct. > > > >> I've noticed that "auto" enables only curves x25519 and P-256 (which is > >> what I'd want to use - but somehow unexpected with regard to the > >> announcement). > > > > Why do you believe this is the case? > > > > Tested with a build of today's current: > - httpd started with ecdhe "auto" in /etc/httpd.conf > - then trying to connect via openssl s_client with -groups P-384 option > doesn't negotiate a cipher suite. > > However, specifying -groups P-256 works. I don't know how to specify > x25519 with OpenBSD's openssl s_client (it's not yet listed in openssl > ecparam -list_curves output) but SSL Labs successfully negotiates via > x25519 and P-256 (but not P-384). P-384 doesn't seem to be enabled with > "auto". > > Another confusing test result: > - httpd started with ecdhe "secp384r1" (P-384) > - then trying to connect via openssl s_client with -groups P-384 option > also doesn't negotiate a cipher suite! > > However, SSL Labs successfully connects to httpd and confirms support > for secp384r1. > > Can you reproduce this? > > >> Diff is attached which clarifies the meaning of "auto" in httpd.conf.5. > > > > There are some documentation improvements that could be used here, > however the > > meaning of auto for httpd.conf.5 needs to refer to the meaning of "auto" > for > > libtls (currently tls_config_set_ecdhecurve()). Otherwise libtls changes > and > > httpd becomes out of date. > > > >> There currently seems to be no way to explicitly specify x25519, or to > >> specify multiple colon separated curves with the ecdhe statement. Would > >> it make sense to change semantics and make the ecdhe statement in > >> httpd.conf consistent with the recent changes to openssl s_client > >> -groups (e.g., to also allow more common names like P-256 instead of > >> prime256v1)? > > > > Yes - tls_config_set_ecdhecurve() needs to change to accept the same > colon > > separate list of priority ordered curve names, that > SSL_set1_curves_list() > > accepts. > > > > > >
Re: dhcpd.conf(5): "domain name" -> "hostname" for next-server option
Theo Buehler writes: > On Wed, Jan 11, 2017 at 09:30:15PM +0100, Theo Buehler wrote: >> The TOK_NEXT_SERVER case in parse_statement() calls >> parse_ip_addr_or_hostname(), >> so I think the next-server option wants a host name, not a domain name: > > Any takers? I previously suggested 'host name', but the rest of the page > writes 'hostname', so let's go with that. "hostname" sounds less misleading indeed, I believe what is really meant here is "a name that can be looked up in the DNS". Most occurrences of "domain name" in this manpage carry the same intent. Do we want to convert those? FWIW, https://tools.ietf.org/html/rfc7719#section-2 acknowledges the fact that "host name" has multiple meanings: is it a FQDN, only the first label of an FQDN...? -- jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF DDCC 0DFA 74AE 1524 E7EE
Re: specify curves via ecdhe statement in httpd.conf
On 02/04/17 05:26, Joel Sing wrote: On Wednesday 01 February 2017 15:41:29 Andreas Bartelt wrote: Hello, after reading the LibreSSL accouncement from today, I assumed that specifying ecdhe "auto" in /etc/httpd.conf would enable X25519, P-256 and P-384 on current. This is correct. I've noticed that "auto" enables only curves x25519 and P-256 (which is what I'd want to use - but somehow unexpected with regard to the announcement). Why do you believe this is the case? Tested with a build of today's current: - httpd started with ecdhe "auto" in /etc/httpd.conf - then trying to connect via openssl s_client with -groups P-384 option doesn't negotiate a cipher suite. However, specifying -groups P-256 works. I don't know how to specify x25519 with OpenBSD's openssl s_client (it's not yet listed in openssl ecparam -list_curves output) but SSL Labs successfully negotiates via x25519 and P-256 (but not P-384). P-384 doesn't seem to be enabled with "auto". Another confusing test result: - httpd started with ecdhe "secp384r1" (P-384) - then trying to connect via openssl s_client with -groups P-384 option also doesn't negotiate a cipher suite! However, SSL Labs successfully connects to httpd and confirms support for secp384r1. Can you reproduce this? Diff is attached which clarifies the meaning of "auto" in httpd.conf.5. There are some documentation improvements that could be used here, however the meaning of auto for httpd.conf.5 needs to refer to the meaning of "auto" for libtls (currently tls_config_set_ecdhecurve()). Otherwise libtls changes and httpd becomes out of date. There currently seems to be no way to explicitly specify x25519, or to specify multiple colon separated curves with the ecdhe statement. Would it make sense to change semantics and make the ecdhe statement in httpd.conf consistent with the recent changes to openssl s_client -groups (e.g., to also allow more common names like P-256 instead of prime256v1)? Yes - tls_config_set_ecdhecurve() needs to change to accept the same colon separate list of priority ordered curve names, that SSL_set1_curves_list() accepts.
