Re: TLS suddenly not working over IKED site-to-site

[Theodore Wynnychenko]

Hello again: 

I updated my iked endpoints to the most recent (12/14/18) amd64 snapshot today, 
and am still having problems with secure connections.

So, today, I am just looking at the gateway machines. 

The iked vpn tunnel gets established without an issue. 

# ipsecctl -s all 
FLOWS: 
flow esp in from xx.xx.xx.xx to 172.30.1.20 peer xx.xx.xx.xx srcid FQDN/x.x.x 
dstid FQDN/x.x.x type use 
flow ipcomp in from 172.30.6.0/23 to 172.30.0.0/22 peer xx.xx.xx.xx srcid 
FQDN/x.x.x dstid FQDN/x.x.x type use 
flow ipcomp out from 172.30.0.0/22 to 172.30.6.0/23 peer xx.xx.xx.xx srcid 
FQDN/x.x.x dstid FQDN/x.x.x type require 
flow esp out from 172.30.1.20 to xx.xx.xx.xx peer xx.xx.xx.xx srcid FQDN/x.x.x 
com dstid FQDN/x.x.x type require 

SAD: 
ipcomp tunnel from 172.30.1.20 to xx.xx.xx.xx spi 0x54ab comp deflate 
ipcomp tunnel from xx.xx.xx.xx to 172.30.1.20 spi 0x8bf1 comp deflate 
esp tunnel from 172.30.1.20 to xx.xx.xx.xx spi 0x0934ef93 auth hmac-sha2-256 
enc aes-256 
esp transport from xx.xx.xx.xx to 172.30.1.20 spi 0x29a95d18 auth hmac-sha2-256 
enc aes-256 
esp transport from 172.30.1.20 to xx.xx.xx.xx spi 0x7b90f84c auth hmac-sha2-256 
enc aes-256 
esp tunnel from xx.xx.xx.xx to 172.30.1.20 spi 0xa9238cfb auth hmac-sha2-256 
enc aes-256 


I have also added "set skip on { lo enc0 }" to pf.conf on both gateways (trying 
to take that out of the equation). 


If, on the remote gateway I run: 
# nc -l https 

Then, when, on the local gateway I run: 
# nc remote.gateway https 
(( and enter "some text" and  )) 

On the remote gateway I see: 
"some text" 

OK, traffic is flowing from one to the other and allowed on https.  Right? 

If I run s_server on the remote gateway: 
# openssl s_server -state -accept https -CAfile /etc/ssl/cert.pem -cert 
/etc/ssl/server.crt -key /etc/ssl/private/server.key

The s_server starts: 
Using auto DH parameters 
Using default temp ECDH parameters 
ACCEPT 

When I try connecting with s_client on the local gateway: 
# openssl s_client -state -connect remote.gateway:https 

All I see is: 
CONNECTED(0003) 
SSL_connect:before/connect initialization 
SSL_connect:SSLv3 write client hello A 


And there is no output on the server side (the remote gateway). 

At the same time, tcpdump of enc0 shows: 

On the local gateway: 

17:37:00.199269 (authentic,confidential): SPI 0x7b90f84c: 172.30.1.20.20692 > 
172.30.6.201.443: S 3823001077:3823001077(0) win 16384  (encap)

17:37:00.235313 (authentic,confidential): SPI 0x29a95d18: 172.30.6.201.443 > 
172.30.1.20.20692: S 833135398:833135398(0) ack 3823001078 win 16384  (DF) 
(encap)

17:37:00.235335 (authentic,confidential): SPI 0x7b90f84c: 172.30.1.20.20692 > 
172.30.6.201.443: . ack 1 win 256  (encap)

17:37:00.236086 (unprotected): SPI 0x54ab: 172.30.1.20.20692 > 
172.30.6.201.443: P 1:197(196) ack 1 win 256  (encap)

17:37:01.726509 (unprotected): SPI 0x54ab: 172.30.1.20.20692 > 
172.30.6.201.443: P 1:197(196) ack 1 win 256  (encap)

17:37:04.726571 (unprotected): SPI 0x54ab: 172.30.1.20.20692 > 
172.30.6.201.443: P 1:197(196) ack 1 win 256  (encap)

17:37:07.777123 (authentic,confidential): SPI 0x7b90f84c: 172.30.1.20.20692 > 
172.30.6.201.443: F 197:197(0) ack 1 win 256  (encap)

17:37:07.820525 (authentic,confidential): SPI 0x29a95d18: 172.30.6.201.443 > 
172.30.1.20.20692: . ack 1 win 271  (DF) (encap)

17:37:10.726697 (unprotected): SPI 0x54ab: 172.30.1.20.20692 > 
172.30.6.201.443: FP 1:197(196) ack 1 win 256  (encap)

17:37:11.724643 (authentic,confidential): SPI 0x29a95d18: 172.30.6.201.443 > 
172.30.1.20.20692: F 1:1(0) ack 1 win 271  (DF) (encap)

17:37:11.724680 (authentic,confidential): SPI 0x7b90f84c: 172.30.1.20.20692 > 
172.30.6.201.443: F 197:197(0) ack 2 win 256  (encap)

17:37:11.759035 (authentic,confidential): SPI 0x29a95d18: 172.30.6.201.443 > 
172.30.1.20.20692: . ack 1 win 271  (DF) 
(encap)


But, tcpdump of enc0 on the remote gateway only shows: 

17:37:00.207517 (authentic,confidential): SPI 0x7b90f84c: 172.30.1.20.20692 > 
172.30.6.201.443: S 3823001077:3823001077(0) win 16384  (encap)

17:37:00.207551 (authentic,confidential): SPI 0x29a95d18: 172.30.6.201.443 > 
172.30.1.20.20692: S 833135398:833135398(0) ack 3823001078 win 16384  (DF) 
(encap)

17:37:00.244461 (authentic,confidential): SPI 0x7b90f84c: 172.30.1.20.20692 > 
172.30.6.201.443: . ack 1 win 256  (encap)

17:37:07.792702 (authentic,confidential): SPI 0x7b90f84c: 172.30.1.20.20692 > 
172.30.6.201.443: F 197:197(0) ack 1 win 256  (encap)

17:37:07.792724 (authentic,confidential): SPI 0x29a95d18: 172.30.6.201.443 > 
172.30.1.20.20692: . ack 1 win 271  (DF) (encap)


Needless to say, if I try these connections WITHOUT traversing the iked vpn, 
the openssl s_client to s_server connection works as expected.

Not being in any way an expert on these things, I cannot understand why 
"regular" tcp packets are able to traverse the VPN and emerge on the other 
side, while tcp pakets to the same port attempting to establish a secure 
co

Re: pkg_add source code modification

[Juan Francisco Cantero Hurtado]

On Sat, Dec 15, 2018 at 07:49:19PM +0200, Mihai Popescu wrote:
> Hello,
> 
> I want to modify the char used for pkg_add (and other pkg_ suite)
> progress bar from "*" to "|" but i am unable to figure out where is
> the actual code for this. I managed to found /usr/sbin/pkg_add but
> there are another links in there, and perl for me is a no idea
> language.
> 
> It could be that what I want is not so simple or it is not
> recommended. I will accept that gladly if that's the case. Could you
> give me some hints for this modification?

Function "show" in
/usr/src/usr.sbin/pkg_add/OpenBSD/ProgressMeter/Term.pm .


-- 
Juan Francisco Cantero Hurtado http://juanfra.info

Re: pkg_add source code modification

[Christian Weisgerber]

On 2018-12-15, Mihai Popescu  wrote:

> I want to modify the char used for pkg_add (and other pkg_ suite)
> progress bar from "*" to "|" but i am unable to figure out where is
> the actual code for this. I managed to found /usr/sbin/pkg_add but
> there are another links in there, and perl for me is a no idea
> language.

Well, you need to understand that the code for the pkg tools is
mostly found in numerous Perl modules--the files in the OpenBSD
directory under src/usr.sbin/pkg_add.

>From there it's a reasonable guess that this asterisk probably shows
up as some sort of string or character constant, i.e., something
like '*' or "*", so with the proper shell quoting you run a recursive
grep for this... Bingo, there it is.

-- 
Christian "naddy" Weisgerber  na...@mips.inka.de

Re: procmail and new grammar in smtpd.conf

[Marcus MERIGHI]

cl...@syntheticnation.com (schwack), 2018.12.11 (Tue) 22:36 (CET):
> On Wed, Dec 05, 2018 at 10:07:34AM -0500, Daniel Corbe wrote:
> > at 6:22 AM, Eda Sky  wrote:
> > 
> > 
> > > Executive summary: delete the procmail port; the code is not safe and
> > > should not be used as a basis for any further work.
> 
> Is maildrop a recommended alternative? 

$ pkg_info fdm

"fdm is a simple, lightweight replacement for mail fetch, filter and
delivery programs such as fetchmail and procmail."

Using it since my departure from procmail, no problems seen.

Marcus

Re: pkg_add source code modification

[Ingo Schwarze]

Hi,

Mihai Popescu wrote on Sat, Dec 15, 2018 at 07:49:19PM +0200:

> I want to modify the char used for pkg_add (and other pkg_ suite)
> progress bar from "*" to "|" but i am unable to figure out where is
> the actual code for this. I managed to found /usr/sbin/pkg_add but

LOL, thanks for the good laugh.

That's typical for pkg_add(1).  There are few programs in the tree -
even including unmaintained legacy stuff - where it is harder to
find anything.  In pkg_add(1), code for each object is typically
scattered across many files, each file typically mixes code for
many different objects, the filenames almost never correspond to
the names of the objects they implement, and many functions are so
small that they do almost nothing, making call trees hard to unravel.

Have fun hunting your wild geese!
  Ingo

Re: pkg_add source code modification

[Hiltjo Posthuma]

On Sat, Dec 15, 2018 at 07:49:19PM +0200, Mihai Popescu wrote:
> Hello,
> 
> I want to modify the char used for pkg_add (and other pkg_ suite)
> progress bar from "*" to "|" but i am unable to figure out where is
> the actual code for this. I managed to found /usr/sbin/pkg_add but
> there are another links in there, and perl for me is a no idea
> language.
> 
> It could be that what I want is not so simple or it is not
> recommended. I will accept that gladly if that's the case. Could you
> give me some hints for this modification?
> 
> Thank you.
> 

Hi,

It is in:

/usr/src/usr.sbin/pkg_add/OpenBSD/ProgressMeter/Term.pm

sub show

Maybe in the christmas style you could use a snowman instead :P

☃

-- 
Kind regards,
Hiltjo

pkg_add source code modification

[Mihai Popescu]

Hello,

I want to modify the char used for pkg_add (and other pkg_ suite)
progress bar from "*" to "|" but i am unable to figure out where is
the actual code for this. I managed to found /usr/sbin/pkg_add but
there are another links in there, and perl for me is a no idea
language.

It could be that what I want is not so simple or it is not
recommended. I will accept that gladly if that's the case. Could you
give me some hints for this modification?

Thank you.

Re: TLS suddenly not working over IKED site-to-site

[Zhi-Qiang Lei]

Hi,

This issue varies to different destinations on my side. I cannot browse 
www.google.com  and twitter.com  
and www.facebook.com  (and possibly more), while I 
can browse duckduckgo.com . Firefox returns Network 
Protocol Error on www.google.com  and timeout on 
twitter.com  and www.facebook.com 
. Additionally, IMAPS and SMTPS is working on Gmail, 
this email is sending via the VPN.

~> openssl s_client -connect www.google.com:443 -showcerts
CONNECTED(0005)
depth=2 OU = GlobalSign Root CA - R2, O = GlobalSign, CN = GlobalSign
verify return:1
depth=1 C = US, O = Google Trust Services, CN = Google Internet Authority G3
verify return:1
depth=0 C = US, ST = California, L = Mountain View, O = Google LLC, CN = 
www.google.com
verify return:1
---
Certificate chain
 0 s:/C=US/ST=California/L=Mountain View/O=Google LLC/CN=www.google.com
   i:/C=US/O=Google Trust Services/CN=Google Internet Authority G3
-BEGIN CERTIFICATE-
MIIEgjCCA2qgAwIBAgIIaLoHUPAeg/4wDQYJKoZIhvcNAQELBQAwVDELMAkGA1UE
BhMCVVMxHjAcBgNVBAoTFUdvb2dsZSBUcnVzdCBTZXJ2aWNlczElMCMGA1UEAxMc
R29vZ2xlIEludGVybmV0IEF1dGhvcml0eSBHMzAeFw0xODExMjcxNDAyMDBaFw0x
OTAyMTkxNDAyMDBaMGgxCzAJBgNVBAYTAlVTMRMwEQYDVQQIDApDYWxpZm9ybmlh
MRYwFAYDVQQHDA1Nb3VudGFpbiBWaWV3MRMwEQYDVQQKDApHb29nbGUgTExDMRcw
FQYDVQQDDA53d3cuZ29vZ2xlLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC
AQoCggEBAKhtF0MjB2unptytQW44dm3c9eL3f3YrxJ684rqX8c901CD73NCO+vcF
iVd0c6PiYpYK/kw9vRDXNrognt3CKYWVq/FdTlrjuKWExt7qD/sxZCKetTl5qekm
V4PwcbEvS98NF9vXIIIzOTK3WdYjz573ydyCWpA32qOLpCt8a6XoedFzX7KiUaGS
RPPNQI0+xZgow7jgNpZklB+iEwymSgFrM5SHxp4fouJMVG3BnJqXyhTdz4U4Ck+S
3gVEBNKc/y+ZKGplwbZ5NngYaov7U9uItceawa5xplcN0A1RcDmVaaRtsF51ktVQ
pZaAauc7LibJc9j4+ov5wTYYDwrxDK8CAwEAAaOCAUIwggE+MBMGA1UdJQQMMAoG
CCsGAQUFBwMBMBkGA1UdEQQSMBCCDnd3dy5nb29nbGUuY29tMGgGCCsGAQUFBwEB
BFwwWjAtBggrBgEFBQcwAoYhaHR0cDovL3BraS5nb29nL2dzcjIvR1RTR0lBRzMu
Y3J0MCkGCCsGAQUFBzABhh1odHRwOi8vb2NzcC5wa2kuZ29vZy9HVFNHSUFHMzAd
BgNVHQ4EFgQUz7BpFM91Drzs5f0URBWlje274G0wDAYDVR0TAQH/BAIwADAfBgNV
HSMEGDAWgBR3wrhQmmd2drEtwobQg6B+pn66SzAhBgNVHSAEGjAYMAwGCisGAQQB
1nkCBQMwCAYGZ4EMAQICMDEGA1UdHwQqMCgwJqAkoCKGIGh0dHA6Ly9jcmwucGtp
Lmdvb2cvR1RTR0lBRzMuY3JsMA0GCSqGSIb3DQEBCwUAA4IBAQABZMq2qOr84g64
B0gEEkvQKIuNX+a2PB5R/IkhehqlH13120pTF1uoUBob9GCpmn2HT3KF88FiVzZ9
hfP2VturJv2WSzn1XSQGsba4oO6uiKWn1bAcXKpHWy+r+vnmuNBgLDNQ6uX3nC3A
5MrhGVv6D/7k5NPzOnI6mclBA/U/dE2Tp48Ej9RYg8rTjWajxUX4TTSskJZwmwXx
klEVY9Q4Gi3s5TrmDknusXhsIN9INzWDypB7h8Q5/IwjosMe2/rVK28BeSVtXRRy
xDI/NgavhvJJdAYOPiO0JW38QEHxKO3Fp7eO2zmZlVTbrq/VARguWl3qag526weW
4CNWWXYg
-END CERTIFICATE-
 1 s:/C=US/O=Google Trust Services/CN=Google Internet Authority G3
   i:/OU=GlobalSign Root CA - R2/O=GlobalSign/CN=GlobalSign
-BEGIN CERTIFICATE-
MIIEXDCCA0SgAwIBAgINAeOpMBz8cgY4P5pTHTANBgkqhkiG9w0BAQsFADBMMSAw
HgYDVQQLExdHbG9iYWxTaWduIFJvb3QgQ0EgLSBSMjETMBEGA1UEChMKR2xvYmFs
U2lnbjETMBEGA1UEAxMKR2xvYmFsU2lnbjAeFw0xNzA2MTUwMDAwNDJaFw0yMTEy
MTUwMDAwNDJaMFQxCzAJBgNVBAYTAlVTMR4wHAYDVQQKExVHb29nbGUgVHJ1c3Qg
U2VydmljZXMxJTAjBgNVBAMTHEdvb2dsZSBJbnRlcm5ldCBBdXRob3JpdHkgRzMw
ggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDKUkvqHv/OJGuo2nIYaNVW
XQ5IWi01CXZaz6TIHLGp/lOJ+600/4hbn7vn6AAB3DVzdQOts7G5pH0rJnnOFUAK
71G4nzKMfHCGUksW/mona+Y2emJQ2N+aicwJKetPKRSIgAuPOB6Aahh8Hb2XO3h9
RUk2T0HNouB2VzxoMXlkyW7XUR5mw6JkLHnA52XDVoRTWkNty5oCINLvGmnRsJ1z
ouAqYGVQMc/7sy+/EYhALrVJEA8KbtyX+r8snwU5C1hUrwaW6MWOARa8qBpNQcWT
kaIeoYvy/sGIJEmjR0vFEwHdp1cSaWIr6/4g72n7OqXwfinu7ZYW97EfoOSQJeAz
AgMBAAGjggEzMIIBLzAOBgNVHQ8BAf8EBAMCAYYwHQYDVR0lBBYwFAYIKwYBBQUH
AwEGCCsGAQUFBwMCMBIGA1UdEwEB/wQIMAYBAf8CAQAwHQYDVR0OBBYEFHfCuFCa
Z3Z2sS3ChtCDoH6mfrpLMB8GA1UdIwQYMBaAFJviB1dnHB7AagbeWbSaLd/cGYYu
MDUGCCsGAQUFBwEBBCkwJzAlBggrBgEFBQcwAYYZaHR0cDovL29jc3AucGtpLmdv
b2cvZ3NyMjAyBgNVHR8EKzApMCegJaAjhiFodHRwOi8vY3JsLnBraS5nb29nL2dz
cjIvZ3NyMi5jcmwwPwYDVR0gBDgwNjA0BgZngQwBAgIwKjAoBggrBgEFBQcCARYc
aHR0cHM6Ly9wa2kuZ29vZy9yZXBvc2l0b3J5LzANBgkqhkiG9w0BAQsFAAOCAQEA
HLeJluRT7bvs26gyAZ8so81trUISd7O45skDUmAge1cnxhG1P2cNmSxbWsoiCt2e
ux9LSD+PAj2LIYRFHW31/6xoic1k4tbWXkDCjir37xTTNqRAMPUyFRWSdvt+nlPq
wnb8Oa2I/maSJukcxDjNSfpDh/Bd1lZNgdd/8cLdsE3+wypufJ9uXO1iQpnh9zbu
FIwsIONGl1p3A8CgxkqI/UAih3JaGOqcpcdaCIzkBaR9uYQ1X4k2Vg5APRLouzVy
7a8IVk6wuy6pm+T7HT4LY8ibS5FEZlfAFLSW8NwsVz9SBK2Vqn1N0PIMn5xA6NZV
c7o835DLAFshEWfC7TIe3g==
-END CERTIFICATE-
---
Server certificate
subject=/C=US/ST=California/L=Mountain View/O=Google LLC/CN=www.google.com
issuer=/C=US/O=Google Trust Services/CN=Google Internet Authority G3
---
No client certificate CA names sent
Server Temp Key: ECDH, X25519, 253 bits
---
SSL handshake has read 2945 bytes and written 285 bytes
---
New, TLSv1/SSLv3, Cipher is ECDHE-RSA-CHACHA20-POLY1305
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
Protocol  : TLSv1.2
Cipher: ECDHE-RSA-CHACHA20-POLY1305
Session-ID: 2319C8A3053A

Re: SSH server immediately closes connection

[Родин Максим]

Hello,
That was my fault. I misconfigured my login.conf last time.

14.12.2018 16:14, Nick Holland пишет:

On 12/14/18 00:27, Максим wrote:

Hello,
I've got a PC running OpenBSD current.
After the latest upgrade I cannot ssh to it.

When I run "ssh 10.26.5.70"
I get this:
"Connection to 10.26.5.70 closed by remote host.
  Connection to 10.26.5.70 closed."
As an SSH client I use another OpenBSD box and a Linux machine
with the same result.
When I run "ssh -vvv 10.26.5.70"
the last messages are:

"debug3: receive packet: type 52
debug1: Authentication succeeded (publickey).
Authenticated to 10.26.5.70 ([10.26.5.70]:22).
debug1: channel 0: new [client-session]
debug3: ssh_session2_open: channel_new: 0
debug2: channel 0: send open
debug3: send packet: type 90
debug1: Requesting no-more-sessi...@openssh.com
debug3: send packet: type 80
debug1: Entering interactive session.
debug1: pledge: network
debug3: send packet: type 1
debug1: channel 0: free: client-session, nchannels 1
debug3: channel 0: status: The following connections are open:
   #0 client-session (t3 nr0 i0/0 o0/0 e[write]/0 fd 4/5/6 sock -1 cc -1)

debug3: fd 1 is not O_NONBLOCK
Connection to 10.26.5.70 closed by remote host.
Connection to 10.26.5.70 closed.
Transferred: sent 2644, received 1932 bytes, in 0.0 seconds
Bytes per second: sent 1085498.2, received 793185.5
debug1: Exit status -1"


No errors in /var/log/daemon
No errors in /var/log/authlog

The result doesn't depend on the user which I use to login.


I just happened to have upgraded a system last night to the most recent
snapshot, I am NOT having any such problem.
OpenBSD 6.4-current (GENERIC.MP) #510: Thu Dec 13 06:20:42 MST 2018
 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP

So ... Doesn't appear to be a systemic problem, most likely either a
knob you twisted before the upgrade or something about your upgrade process.

You need to provide more details about what you did...both before and
during the upgrade...and some indication of what platform you are
running and the snapshot you upgraded to.

Nick.



--
С уважением,
Родин Максим

TLS with popa3d

[Peter J. Philipp]

Hi,

A while back I mentioned I'd like to write a pop3 server, and someone hinted
to me to use the popa3d that is in the attic.

I've hacked up popa3d to use tls_server() but I'm at a dillema.  Popa3d as
you know forks and privseps into a popa3d user to handle AUTHORIZATION tasks
while keeping the descriptor open to both the popa3d child and the root 
process.

The whole thing looks like this in the DESIGN file (somewhat):

-->
 startup as root
|
-
|child  |parent
v   v
drop to user popa3d,still as root,
handle the AUTHORIZATIONwait for and
state, write the results, - - > read the authentication
and exitinformation
|
-
|child  |parent
v   v
getspnam(3), crypt(3),  wait for and
check, write the result,  - - > read the authentication
and exit (to clean up)  result
|
v
drop to the authenticated user,
handle the TRANSACTION state,
possibly UPDATE the mailbox,
and exit
<--

Because of the nature of a fork, filedescriptors are duplicated.  When I
converted these filedescriptors to (struct tls *) contexes I fell into a 
problem with TLS.  In the area around the TRANSACTION state, so after 
authenticating, I get a TLS error:

Dec 14 22:34:15 beta popa3d[52542]: Session from ::1
Dec 14 22:34:24 beta popa3d[52542]: Authentication passed for testpop
Dec 14 22:34:24 beta popa3d[52542]: 0 messages (0 bytes) loaded
Dec 14 22:34:24 beta popa3d[52542]: handshake failed: error:140260FC:SSL 
routines:ACCEPT_SR_CLNT_HELLO:unknown protocol
Dec 14 22:34:24 beta popa3d[52542]: handshake failed: error:140260FC:SSL 
routines:ACCEPT_SR_CLNT_HELLO:unknown protocol

I attribute this to TLS having a counter or something to keep state and because
of fork() the two identical TLS contexes get desyncronized.

Question then is: Is there a way to do this despite?  Is there a way to tell
TLS to forget the forked child and continue with the root parent?

Would the only design that works for this be having a forked TLS process that
multiplexes the whole session?

Thanks and regards,
-peter