Re: nc(1) fails the tls handshake when destination ends with a full stop
On 2021-05-30 19:55 +02, Theo Buehler wrote: > On Sun, May 30, 2021 at 01:43:54PM -0400, Daniel Jakots wrote: >> On Sun, 30 May 2021 17:45:22 +0200, Theo Buehler >> wrote: >> >> > Unsure. If people really think this is useful and necessary, I can be >> > convinced. It's easy enough to do. And you're right, curl strips the >> > trailing dot after resolving a host name for SNI and HTTP host header. >> >> Given the current error message makes it hard to understand what the >> problem is, I think it's nicer to fix the user error like curl(1) does. > > What I do not quite see is why you would want or expect to be able to > have a trailing dot there. None of nc's examples have it and in ftp/curl > it seems even weirder. > It's the name of the thing (RFC 8499): Fully-Qualified Domain Name (FQDN): This is often just a clear way of saying the same thing as "domain name of a node", as outlined above. However, the term is ambiguous. Strictly speaking, a fully-qualified domain name would include every label, including the zero-length label of the root: such a name would be written "www.example.net." (note the terminating dot). But, because every name eventually shares the common root, names are often written relative to the root (such as "www.example.net") and are still called "fully qualified". This term first appeared in [RFC819]. In practical terms, if one adds the trailing dot, the stub resolver in libc (asr) will not try the search list if the original name does not resolve. www.openbsd.org. is really only www.openbsd.org and not maybe www.openbsd.org.home. or www.openbsd.org.lan. or some such. -- I'm not entirely sure you are real.
Openbsd VMM with VLAN
Hi all
i have two Openbsd box Running Like Below one As Firewall and Another one As
VMM
With two VLAN's
OPENBSD_FIREWALL
IoT_AP (VLAN10) . -VLAN10
|--OpenWRT-em0---| ---pf --em1--Internet
||- VLAN20
trusted_AP(VLAN20)
this Works fine
Another Separate OpenBSD Box for VM
openbsd(vmGuest)---vether0---openbsdHost——NAT—em0--OpenBSD_FW--Internet
is it possible Add openbsd(vmguest) to VLAN10 network
this is MY vm config [HomeAssistance]
switch "uplink" {
interface bridge1
}
vm "hass" {
disable
owner irshad
memory 2G
disk "/home/irshad/iso/disk.qcow2"
interface {
switch "uplink"
lladdr fe:e1:bb:01:01:01
}
}
pf questions
I’m setting up on 6.9-release a (for now) IPv4-only firewall with multiple public addresses and multiple subnets behind it, and have a couple of questions related to connections originating from the firewall itself to which I haven’t found definitive answers. When not overridden (for example, by ‘ftp-proxy -a ’) which of the public addresses will be chosen as the source address for connections to the Internet originating on the firewall? It would make sense to me for the one address not declared as an alias to always be chosen, but I haven’t found anything that states this to be true. I want to (for example) keep traffic from systems I control separate from that from the WiFi subnet (which I’ll NAT to a different public address). I plan to use tags to control policy, initially tagging each new connection based mostly (but not entirely) on which interface it arrives through. But, unless I’m missing something, connections originating on the firewall can’t be tagged this way since they don’t arrive through any interface. Which also seems to mean that all policy decisions must be made outbound, since that’s the only time that connections originating on the firewall will pass through an interface. And I haven’t found any way of filtering on untagged connections (something like ‘! tagged any’ would be nice). I’m sure that my setup isn’t unique, so there must be a good way of dealing with this, but I’ve no idea what it might be. Suggestions, please! -- Dave Anderson d...@daveanderson.com
Re: nc(1) fails the tls handshake when destination ends with a full stop
On Sun, 30 May 2021 19:55:42 +0200, Theo Buehler wrote: > On Sun, May 30, 2021 at 01:43:54PM -0400, Daniel Jakots wrote: > > On Sun, 30 May 2021 17:45:22 +0200, Theo Buehler > > wrote: > > > > > Unsure. If people really think this is useful and necessary, I > > > can be convinced. It's easy enough to do. And you're right, curl > > > strips the trailing dot after resolving a host name for SNI and > > > HTTP host header. > > > > Given the current error message makes it hard to understand what the > > problem is, I think it's nicer to fix the user error like curl(1) > > does. > > What I do not quite see is why you would want or expect to be able to > have a trailing dot there. None of nc's examples have it and in > ftp/curl it seems even weirder. I think what happened is I was fucking around with my certificates file, and they're named like example.com.pem. I wanted to check something so I double-clicked on the string and pasted it, and then removed only "pem". I left the trailing dot both out of laziness and because I didn't expect it to break things. I recently learned that you can include the DNS name trailing dot in a url even if it looks weird. But I just tested some more and for instance: https://datatracker.ietf.org./doc/html/rfc6066#section-3 # works https://openbsd.org./ # doesn't work with Error code: SSL_ERROR_ILLEGAL_PARAMETER_ALERT $ nc -zvc datatracker.ietf.org. 443 Connection to datatracker.ietf.org. (4.31.198.44) 443 port [tcp/https] succeeded! nc: tls handshake failed (name `datatracker.ietf.org.' not present in server certificate) (and adding -Tnoname makes it work) so I guess LibreSSL is stricter than OpenSSL?
Re: nc(1) fails the tls handshake when destination ends with a full stop
On Sun, May 30, 2021 at 01:43:54PM -0400, Daniel Jakots wrote: > On Sun, 30 May 2021 17:45:22 +0200, Theo Buehler > wrote: > > > Unsure. If people really think this is useful and necessary, I can be > > convinced. It's easy enough to do. And you're right, curl strips the > > trailing dot after resolving a host name for SNI and HTTP host header. > > Given the current error message makes it hard to understand what the > problem is, I think it's nicer to fix the user error like curl(1) does. What I do not quite see is why you would want or expect to be able to have a trailing dot there. None of nc's examples have it and in ftp/curl it seems even weirder.
Re: nc(1) fails the tls handshake when destination ends with a full stop
On Sun, 30 May 2021 17:45:22 +0200, Theo Buehler wrote: > Unsure. If people really think this is useful and necessary, I can be > convinced. It's easy enough to do. And you're right, curl strips the > trailing dot after resolving a host name for SNI and HTTP host header. Given the current error message makes it hard to understand what the problem is, I think it's nicer to fix the user error like curl(1) does. Thanks, Daniel
Re: Using relayd as a reverse proxy for multiple local servers
I should mention, as I did in a thread months ago, there are extensive example configurations available in '/etc/examples'. Yours would be '/etc/examples/relayd.conf', which illustrates several typical use cases. Also, in future you might want to post the entirety of your configuration files. Otherwise, the responses will be just as vague and it wastes everyone's time (including yours). You may of course "sanitize" any identifying information like hostnames and public ip adressess.
Re: Using relayd as a reverse proxy for multiple local servers
Jean-Pierre de Villiers writes: > Apologies yes, my error. I forgot I divert traffic using pf to my > relayd listener. Ok, I will look into this too. > I've never seen/used a wildcard listen address in relayd before but I'm > guessing that, in your case, a listener is created for each ip on every > interface. This ofcourse raises the question: does every ip on every > one of your interfaces map to one of your hosts? I only have one I and one interface, but multiple hosts. My understanding is that if I had multiple IPs/interfaces, non of this would be an issue. -- Philip K.
Re: nc(1) fails the tls handshake when destination ends with a full stop
On Sun, May 30, 2021 at 02:31:55PM -, Stuart Henderson wrote:
> On 2021-05-30, Theo Buehler wrote:
> > On Sat, May 29, 2021 at 10:37:18PM -0400, Daniel Jakots wrote:
> >> Hi,
> >>
> >> $ nc -zvc openbsd.org 443 # works as expected
> >> Connection to openbsd.org (129.128.5.194) 443 port [tcp/https] succeeded!
> >> TLS handshake negotiated TLSv1.3/AEAD-AES256-GCM-SHA384 with host
> >> openbsd.org
> >> [...]
> >>
> >> $ nc -zvc openbsd.org. 443 # fails
> >> Connection to openbsd.org. (129.128.5.194) 443 port [tcp/https] succeeded!
> >> nc: tls handshake failed (handshake failed: error:1404B42E:SSL
> >> routines:ST_CONNECT:tlsv1 alert protocol version)
> >
> > $ nc -cvz -e openbsd.org openbsd.org. 443 # works
> >
> > Unless -e is given, nc uses 'destination' in its server name indication
> > (SNI) extension. By its specification, (RFC 6066, section 3) the SNI
> > does not contain the trailing dot.
>
> Should something (libtls perhaps; ftp(1) is affected too) strip the dot?
> curl does handle this.
>
Unsure. If people really think this is useful and necessary, I can be
convinced. It's easy enough to do. And you're right, curl strips the
trailing dot after resolving a host name for SNI and HTTP host header.
I would be against doing it server side since contrary to sending IP
addresses it doesn't seem to be common, but doing this client side seems
innocuous.
Index: tls_client.c
===
RCS file: /cvs/src/lib/libtls/tls_client.c,v
retrieving revision 1.45
diff -u -p -r1.45 tls_client.c
--- tls_client.c19 Mar 2018 16:34:47 - 1.45
+++ tls_client.c30 May 2021 15:26:54 -
@@ -279,6 +279,7 @@ static int
tls_connect_common(struct tls *ctx, const char *servername)
{
union tls_addr addrbuf;
+ size_t servername_len;
int rv = -1;
if ((ctx->flags & TLS_CLIENT) == 0) {
@@ -291,6 +292,12 @@ tls_connect_common(struct tls *ctx, cons
tls_set_errorx(ctx, "out of memory");
goto err;
}
+
+ /* If there's a trailing dot, strip it. */
+ servername_len = strlen(servername);
+ if (servername_len > 0 &&
+ ctx->servername[servername_len - 1] == '.')
+ ctx->servername[servername_len - 1] = '\0';
}
if ((ctx->ssl_ctx = SSL_CTX_new(SSLv23_client_method())) == NULL) {
@@ -306,7 +313,7 @@ tls_connect_common(struct tls *ctx, cons
goto err;
if (ctx->config->verify_name) {
- if (servername == NULL) {
+ if (ctx->servername == NULL) {
tls_set_errorx(ctx, "server name not specified");
goto err;
}
@@ -353,10 +360,11 @@ tls_connect_common(struct tls *ctx, cons
* RFC4366 (SNI): Literal IPv4 and IPv6 addresses are not
* permitted in "HostName".
*/
- if (servername != NULL &&
- inet_pton(AF_INET, servername, &addrbuf) != 1 &&
- inet_pton(AF_INET6, servername, &addrbuf) != 1) {
- if (SSL_set_tlsext_host_name(ctx->ssl_conn, servername) == 0) {
+ if (ctx->servername != NULL &&
+ inet_pton(AF_INET, ctx->servername, &addrbuf) != 1 &&
+ inet_pton(AF_INET6, ctx->servername, &addrbuf) != 1) {
+ if (SSL_set_tlsext_host_name(ctx->ssl_conn,
+ ctx->servername) == 0) {
tls_set_errorx(ctx, "server name indication failure");
goto err;
}
Index: tls_server.c
===
RCS file: /cvs/src/lib/libtls/tls_server.c,v
retrieving revision 1.45
diff -u -p -r1.45 tls_server.c
--- tls_server.c13 May 2019 22:36:01 - 1.45
+++ tls_server.c30 May 2021 15:28:10 -
@@ -109,7 +109,7 @@ tls_servername_cb(SSL *ssl, int *al, voi
inet_pton(AF_INET6, name, &addrbuf) == 1)
return (SSL_TLSEXT_ERR_NOACK);
- free((char *)conn_ctx->servername);
+ free(conn_ctx->servername);
if ((conn_ctx->servername = strdup(name)) == NULL)
goto err;
Re: nc(1) fails the tls handshake when destination ends with a full stop
On 2021-05-30, Theo Buehler wrote: > On Sat, May 29, 2021 at 10:37:18PM -0400, Daniel Jakots wrote: >> Hi, >> >> $ nc -zvc openbsd.org 443 # works as expected >> Connection to openbsd.org (129.128.5.194) 443 port [tcp/https] succeeded! >> TLS handshake negotiated TLSv1.3/AEAD-AES256-GCM-SHA384 with host openbsd.org >> [...] >> >> $ nc -zvc openbsd.org. 443 # fails >> Connection to openbsd.org. (129.128.5.194) 443 port [tcp/https] succeeded! >> nc: tls handshake failed (handshake failed: error:1404B42E:SSL >> routines:ST_CONNECT:tlsv1 alert protocol version) > > $ nc -cvz -e openbsd.org openbsd.org. 443 # works > > Unless -e is given, nc uses 'destination' in its server name indication > (SNI) extension. By its specification, (RFC 6066, section 3) the SNI > does not contain the trailing dot. Should something (libtls perhaps; ftp(1) is affected too) strip the dot? curl does handle this.
Re: after upgrade to 6.9, iked does not pass traffic
On Fri, May 28, 2021 at 11:56:54AM +, Leclerc, Sebastien wrote: > >It looks like 'keep state (if-bound)' iked.conf(5) is not present or being > >respected on the return traffic to the VPN device/firewall from your > >internal network. ICMP traffic is coming into the VPN device >encrypted, > >being decrypted and passed to the destination. The destination responds > >back but the VPN device is not taking those responses and pushing them back > >through enc0. > > Thank you for your response Jason. > Here is the relevant pf.conf configuration, keep state (if-bound) is there, > so I don't think it's the cause of the problem : > > pass inet proto udp from 192.168.1.109 to bge0 port 500 > pass inet proto esp from 192.168.1.109 to bge0 > pass on bge0 proto ipencap keep state (if-bound) > pass inet from 192.168.9.208 to vlan0:network > I'm not sure about that bge0 rule. iked.conf(5) mentions ipencap only in the context of enc interfaces. You could try adding 'set skip on enc0' to find out if pf is the problem. If that doesn't help you could share the output of 'ipsecctl -sa' to find out if the IPsec SAs or flows are the problem.
Re: MANPAGER
On 5/29/21 11:18 PM, Allan Streib wrote: Heinrich Rebehn writes: I noticed that OpenBSD 6.8 switched to using less(1) for the manager. While this seems to offer many new useful options, I really dislike the clrscreen upon exit. Have a look at -X argument to less(1): -X | --no-init Disables sending the termcap initialization and deinitialization strings to the terminal. This is sometimes desirable if the deinitialization string does something unnecessary, like clearing the screen. Yeah. PAGER="less -X" is what I am using... regards, chris
Re: pflow on PE router
> "sloppy" seems to fix the issue. I will do more tests this week before > declaring > victory :) > > Thank you Chris. > Get somme ;) Regards Patrick
Re: nc(1) fails the tls handshake when destination ends with a full stop
On Sat, May 29, 2021 at 10:37:18PM -0400, Daniel Jakots wrote: > Hi, > > $ nc -zvc openbsd.org 443 # works as expected > Connection to openbsd.org (129.128.5.194) 443 port [tcp/https] succeeded! > TLS handshake negotiated TLSv1.3/AEAD-AES256-GCM-SHA384 with host openbsd.org > [...] > > $ nc -zvc openbsd.org. 443 # fails > Connection to openbsd.org. (129.128.5.194) 443 port [tcp/https] succeeded! > nc: tls handshake failed (handshake failed: error:1404B42E:SSL > routines:ST_CONNECT:tlsv1 alert protocol version) $ nc -cvz -e openbsd.org openbsd.org. 443 # works Unless -e is given, nc uses 'destination' in its server name indication (SNI) extension. By its specification, (RFC 6066, section 3) the SNI does not contain the trailing dot. The server will treat the name with a trailing dot illegal and send an illegal_parameter alert. For some reason this alert is sent with a record version of TLS1_VERSION instead of TLS1_2_VERSION as required by the TLSv1.3 spec (that may be a bug), so while processing the illegal parameter alert, the client's record layer throws a protocol version error. > And FWIW I get a different error when the destination runs nginx: > > $ nc -zvc px.chown.me. 443 > Connection to px.chown.me. (198.48.202.221) 443 port [tcp/https] succeeded! > nc: tls handshake failed (handshake failed: error:1404B417:SSL > routines:ST_CONNECT:sslv3 alert illegal parameter) This has less to do with the fact that it's nginx and more with the fact that you configured it to use TLSv1.2, so the illegal_parameter alert is received without error. > I checked with -Tnoname to be sure, and it didn't change anything. This disables a check whether the server's certificate matches the server name sent in the SNI extension which comes later in the handshake. > Is that normal? I think so.
Re: pflow on PE router
Le Fri, May 28, 2021 at 03:30:58PM -0700, Chris Cappuccio a écrit : > You might try "set state-defaults pflow, sloppy", also in some scenarios you > might need "set state-policy floating" > > If "sloppy" fixes it, there may be some bugs to hunt. > "sloppy" seems to fix the issue. I will do more tests this week before declaring victory :) Thank you Chris.
Re: MANPAGER
> On 29. May 2021, at 23:08, Leon Fischer wrote: > >> From: Heinrich Rebehn >> Date: Sat, 29 May 2021 21:37:40 +0200 >> >> Hi all, >> >> I noticed that OpenBSD 6.8 switched to using less(1) for the manager. While >> this seems to offer many new useful options, I really dislike the clrscreen >> upon exit. >> I browsed through the less(1) manage to find an option to disable this >> behavior, but to no avail. >> Can anyone tell me how to restore the old behavior without reverting to >> using more(1)? >> I am really used to still seeing the output of the man command when issuing >> the command that i consulted man for. >> >> Many thanks in advance, >> >> Heinrich >> > > Use the -X option. Add `export MANPAGER="less -X"` to ~/.profile to > enable it for man(1), or `export LESS="-X"` to enable it for everything. Thanks to all who replied! I did see LESS_IS_MORE, but there were probably good reasons for the OpenBSD devs to switch to less(1). 'MANPAGER="less -X”` does the trick, I was not aware that "termcap initialization and deinitialization” is responsible for clrscreen. I hope that disabling it completely will not have any adverse side affects. -Heinrich
