From lance at 3t218.org  Thu Dec  1 04:30:39 2016
From: lance at 3t218.org (Lance LeFlore)
Date: Thu, 1 Dec 2016 07:30:39 -0500
Subject: New Ocserv Config-Per-User/Group Configuration Option
In-Reply-To: <CAJU7zaJ7OQSehiMq-bs288C_0XrH4JZyWHadsvfjR7h=AV0pUw@mail.gmail.com>
References: <CACSdvcYjvqtWSQmHsqhWV-GpNTSEt6s3q7H7s0frW9jq1Qw58w@mail.gmail.com>
 <CAJU7zaJ7OQSehiMq-bs288C_0XrH4JZyWHadsvfjR7h=AV0pUw@mail.gmail.com>
Message-ID: <CACSdvcaC7HZGz=D+oeK667yC0r9dNyTusBSE=UmXtM1UFAUJUQ@mail.gmail.com>

On Thu, Dec 1, 2016 at 2:43 AM, Nikos Mavrogiannopoulos
<n.mavrogiannopoulos at gmail.com> wrote:
> Could that be something that can be used by radius as well?

Seems like it could be useful there as well. I don't use the Radius
backend though so I probably shouldn't say much more than that.

Cheers,
Lance


From SAljendi at ledroadwaylighting.com  Fri Dec  2 05:15:13 2016
From: SAljendi at ledroadwaylighting.com (Shadi Aljendi)
Date: Fri, 2 Dec 2016 13:15:13 +0000
Subject: make issue
Message-ID: <YQXPR01MB04530874AAB07A3D66662607A38E0@YQXPR01MB0453.CANPRD01.PROD.OUTLOOK.COM>

# make
make  all-recursive
  CC       libopenconnect_la-openssl-esp.lo
openssl-esp.c: In function 'destroy_esp_ciphers':
openssl-esp.c:48: error: implicit declaration of function 'HMAC_CTX_free'
openssl-esp.c:48: warning: nested extern declaration of 'HMAC_CTX_free'
openssl-esp.c: In function 'init_esp_ciphers':
openssl-esp.c:97: error: implicit declaration of function 'HMAC_CTX_new'
openssl-esp.c:97: warning: nested extern declaration of 'HMAC_CTX_new'
openssl-esp.c:97: warning: assignment makes pointer from integer without a cast
openssl-esp.c:98: warning: assignment makes pointer from integer without a cast
openssl-esp.c: In function 'decrypt_esp_packet':
openssl-esp.c:189: error: implicit declaration of function 'HMAC_CTX_reset'
openssl-esp.c:189: warning: nested extern declaration of 'HMAC_CTX_reset'
Error while executing gcc -DHAVE_CONFIG_H -I. -DLOCALEDIR="/usr/local/share/locale" -I/usr/local/include -Wall -Wextra -Wno-missing-field-initializers -Wno-sign-compare -Wno-unused-parameter -Werror=pointer-to-int-cast -Wdeclaration-after-statement -Werror-implicit-function-declaration -Wformat-nonliteral -Wformat-security -Winit-self -Wmissing-declarations -Wmissing-include-dirs -Wnested-externs -Wpointer-arith -Wwrite-strings -I/usr/include -I/usr/local/include/libxml2 -I/usr/local/include -I/usr/include -I/usr/local/include -g -O2 -MT libopenconnect_la-openssl-esp.lo -MD -MP -MF .deps/libopenconnect_la-openssl-esp.Tpo -c openssl-esp.c -fPIC -DPIC -o .libs/libopenconnect_la-openssl-esp.o
*** Error 1 in . (Makefile:1009 'libopenconnect_la-openssl-esp.lo': @echo "  CC      " libopenconnect_la-openssl-esp.lo;/usr/bin/libtool --s...)
*** Error 1 in . (Makefile:1286 'all-recursive')
*** Error 1 in /root/openconnect-7.07 (Makefile:649 'all')

Sincerely,
?
Shadi Aljendi, Ph.D, M.Sc, B.Sc (Eng)?
Developer/Analyst?
?

?
T: 1.902.450.2222 (Ext. 529)
E: saljendi at ledroadwaylighting.com
W:?http://www.ledroadwaylighting.com
?
NOTICE OF CONFIDENTIALITY
This message contains information that may be confidential and privileged. Unless you are the addressee (or authorized to receive mail for the addressee), you should?not use, copy or disclose to anyone this message or any information contained in this message. If you have received this message in error, please advise the sender by?reply e-mail and delete this message. Thank you for your cooperation.



From SAljendi at ledroadwaylighting.com  Fri Dec  2 05:37:03 2016
From: SAljendi at ledroadwaylighting.com (Shadi Aljendi)
Date: Fri, 2 Dec 2016 13:37:03 +0000
Subject: make issue
Message-ID: <YQXPR01MB045397E3B64E984DEF3D8407A38E0@YQXPR01MB0453.CANPRD01.PROD.OUTLOOK.COM>

Hello,

Sorry for the previous erroneous email. It was sent before I add my comments.

I am trying to install opencoonect on OBSD5.9. Here is what I am getting.

# make
make? all-recursive
? CC?????? libopenconnect_la-openssl-esp.lo
openssl-esp.c: In function 'destroy_esp_ciphers':
openssl-esp.c:48: error: implicit declaration of function 'HMAC_CTX_free'
openssl-esp.c:48: warning: nested extern declaration of 'HMAC_CTX_free'
openssl-esp.c: In function 'init_esp_ciphers':
openssl-esp.c:97: error: implicit declaration of function 'HMAC_CTX_new'
openssl-esp.c:97: warning: nested extern declaration of 'HMAC_CTX_new'
openssl-esp.c:97: warning: assignment makes pointer from integer without a cast
openssl-esp.c:98: warning: assignment makes pointer from integer without a cast
openssl-esp.c: In function 'decrypt_esp_packet':
openssl-esp.c:189: error: implicit declaration of function 'HMAC_CTX_reset'
openssl-esp.c:189: warning: nested extern declaration of 'HMAC_CTX_reset'
Error while executing gcc -DHAVE_CONFIG_H -I. -DLOCALEDIR="/usr/local/share/locale" -I/usr/local/include -Wall -Wextra -Wno-missing-field-initializers -Wno-sign-compare -Wno-unused-parameter -Werror=pointer-to-int-cast -Wdeclaration-after-statement -Werror-implicit-function-declaration -Wformat-nonliteral -Wformat-security -Winit-self -Wmissing-declarations -Wmissing-include-dirs -Wnested-externs -Wpointer-arith -Wwrite-strings -I/usr/include -I/usr/local/include/libxml2 -I/usr/local/include -I/usr/include -I/usr/local/include -g -O2 -MT libopenconnect_la-openssl-esp.lo -MD -MP -MF .deps/libopenconnect_la-openssl-esp.Tpo -c openssl-esp.c -fPIC -DPIC -o .libs/libopenconnect_la-openssl-esp.o
*** Error 1 in . (Makefile:1009 'libopenconnect_la-openssl-esp.lo': @echo "? CC????? " libopenconnect_la-openssl-esp.lo;/usr/bin/libtool --s...)
*** Error 1 in . (Makefile:1286 'all-recursive')
*** Error 1 in /root/openconnect-7.07 (Makefile:649 'all')

Your help is appreciated.
Shadi


Sincerely,
?
Shadi Aljendi, Ph.D, M.Sc, B.Sc (Eng)?
Developer/Analyst?
?

?
T: 1.902.450.2222 (Ext. 529)
E: saljendi at ledroadwaylighting.com
W:?http://www.ledroadwaylighting.com
?
NOTICE OF CONFIDENTIALITY
This message contains information that may be confidential and privileged. Unless you are the addressee (or authorized to receive mail for the addressee), you should?not use, copy or disclose to anyone this message or any information contained in this message. If you have received this message in error, please advise the sender by?reply e-mail and delete this message. Thank you for your cooperation.



From stu at spacehopper.org  Fri Dec  2 06:02:19 2016
From: stu at spacehopper.org (Stuart Henderson)
Date: Fri, 2 Dec 2016 14:02:19 +0000
Subject: make issue
In-Reply-To: <YQXPR01MB045397E3B64E984DEF3D8407A38E0@YQXPR01MB0453.CANPRD01.PROD.OUTLOOK.COM>
References: <YQXPR01MB045397E3B64E984DEF3D8407A38E0@YQXPR01MB0453.CANPRD01.PROD.OUTLOOK.COM>
Message-ID: <20161202140219.32k33btz2vsnbefp@symphytum.spacehopper.org>

On 2016/12/02 13:37, Shadi Aljendi wrote:
> Hello,
> 
> Sorry for the previous erroneous email. It was sent before I add my comments.
> 
> I am trying to install opencoonect on OBSD5.9. Here is what I am getting.

Your easiest fix is to build against gnutls (or even easier, use the
openconnect package, which is also built against gnutls).

> # make
> make? all-recursive
> ? CC?????? libopenconnect_la-openssl-esp.lo
> openssl-esp.c: In function 'destroy_esp_ciphers':
> openssl-esp.c:48: error: implicit declaration of function 'HMAC_CTX_free'
> openssl-esp.c:48: warning: nested extern declaration of 'HMAC_CTX_free'
> openssl-esp.c: In function 'init_esp_ciphers':
> openssl-esp.c:97: error: implicit declaration of function 'HMAC_CTX_new'

Otherwise you'll need to make changes along these lines in several places,
however I don't recommend it.

-#if OPENSSL_VERSION_NUMBER < 0x10100000L
+#if OPENSSL_VERSION_NUMBER < 0x10100000L || defined(LIBRESSL_VERSION_NUMBER)

and

-#if OPENSSL_VERSION_NUMBER >= 0x10100000L
+#if OPENSSL_VERSION_NUMBER >= 0x10100000L && !defined(LIBRESSL_VERSION_NUMBER)



From SAljendi at ledroadwaylighting.com  Fri Dec  2 06:09:15 2016
From: SAljendi at ledroadwaylighting.com (Shadi Aljendi)
Date: Fri, 2 Dec 2016 14:09:15 +0000
Subject: make issue
In-Reply-To: <20161202140219.32k33btz2vsnbefp@symphytum.spacehopper.org>
References: <YQXPR01MB045397E3B64E984DEF3D8407A38E0@YQXPR01MB0453.CANPRD01.PROD.OUTLOOK.COM>
 <20161202140219.32k33btz2vsnbefp@symphytum.spacehopper.org>
Message-ID: <YQXPR01MB04530137A00DDA59370FC45FA38E0@YQXPR01MB0453.CANPRD01.PROD.OUTLOOK.COM>

Thanks Stuart,

Not having X11 because I am working on a SBC, I think I need to go for the second option. Would you please help me locate the places where I need to make the edits?

Thanks,
Shadi

Sincerely,
 
Shadi Aljendi, Ph.D, M.Sc, B.Sc (Eng) 
Developer/Analyst 


Sincerely,
?
Shadi Aljendi, Ph.D, M.Sc, B.Sc (Eng)?
Developer/Analyst?
?

?
T: 1.902.450.2222 (Ext. 529)
E: saljendi at ledroadwaylighting.com
W:?http://www.ledroadwaylighting.com
?
NOTICE OF CONFIDENTIALITY
This message contains information that may be confidential and privileged. Unless you are the addressee (or authorized to receive mail for the addressee), you should?not use, copy or disclose to anyone this message or any information contained in this message. If you have received this message in error, please advise the sender by?reply e-mail and delete this message. Thank you for your cooperation.

-----Original Message-----
From: Stuart Henderson [mailto:stu at spacehopper.org] 
Sent: December 2, 2016 10:02 AM
To: Shadi Aljendi <SAljendi at ledroadwaylighting.com>
Cc: openconnect-devel at lists.infradead.org
Subject: Re: make issue

On 2016/12/02 13:37, Shadi Aljendi wrote:
> Hello,
> 
> Sorry for the previous erroneous email. It was sent before I add my comments.
> 
> I am trying to install opencoonect on OBSD5.9. Here is what I am getting.

Your easiest fix is to build against gnutls (or even easier, use the openconnect package, which is also built against gnutls).

> # make
> make? all-recursive
> ? CC?????? libopenconnect_la-openssl-esp.lo
> openssl-esp.c: In function 'destroy_esp_ciphers':
> openssl-esp.c:48: error: implicit declaration of function 'HMAC_CTX_free'
> openssl-esp.c:48: warning: nested extern declaration of 'HMAC_CTX_free'
> openssl-esp.c: In function 'init_esp_ciphers':
> openssl-esp.c:97: error: implicit declaration of function 'HMAC_CTX_new'

Otherwise you'll need to make changes along these lines in several places, however I don't recommend it.

-#if OPENSSL_VERSION_NUMBER < 0x10100000L
+#if OPENSSL_VERSION_NUMBER < 0x10100000L || 
+defined(LIBRESSL_VERSION_NUMBER)

and

-#if OPENSSL_VERSION_NUMBER >= 0x10100000L
+#if OPENSSL_VERSION_NUMBER >= 0x10100000L && 
+!defined(LIBRESSL_VERSION_NUMBER)



From stu at spacehopper.org  Fri Dec  2 09:56:58 2016
From: stu at spacehopper.org (Stuart Henderson)
Date: Fri, 2 Dec 2016 17:56:58 +0000
Subject: make issue
In-Reply-To: <YQXPR01MB04530137A00DDA59370FC45FA38E0@YQXPR01MB0453.CANPRD01.PROD.OUTLOOK.COM>
References: <YQXPR01MB045397E3B64E984DEF3D8407A38E0@YQXPR01MB0453.CANPRD01.PROD.OUTLOOK.COM>
 <20161202140219.32k33btz2vsnbefp@symphytum.spacehopper.org>
 <YQXPR01MB04530137A00DDA59370FC45FA38E0@YQXPR01MB0453.CANPRD01.PROD.OUTLOOK.COM>
Message-ID: <20161202175658.qfmchwbsopzl5ytw@symphytum.spacehopper.org>

On 2016/12/02 14:09, Shadi Aljendi wrote:
> Thanks Stuart,
> 
> Not having X11 because I am working on a SBC,

X11 isn't required for gnutls (though I do have plenty of SBCs that have X
libraries installed for packages without actually running X themselves).

> I think I need to go for the second option. Would you please help me
> locate the places where I need to make the edits?

Everywhere that OPENSSL_VERSION_NUMBER is compared against 0x10100000L.



From nyarly at gmail.com  Mon Dec  5 11:11:06 2016
From: nyarly at gmail.com (Judson Lester)
Date: Mon, 5 Dec 2016 11:11:06 -0800
Subject: No auth node
Message-ID: <CAOpbp3fqd97qXsJJ68=F1wUK1E28eDqxxd8yM8MOvTjNRP=3Lw@mail.gmail.com>

I'm trying to connect to my company's Cisco VPN. Openconnect worked
for a while, but they've since added the "posture assessment" module.
I've been working through getting that to work on my machine, which
has been challenging.

As an interim measure, I'm picking a trick from a colleague and
setting up a csd-wrapper which simply says "posture assessment failed"
- at the moment, PA is an interim measure and success is not (supposed
to be) required to access the VPN.

I'm not sure if the CSD stuff is related, but now after the assessment
completes, I get a credentials challenge, which is followed by "XML
response has no 'auth' node." How should I proceed?

Thanks,
Judson


From edmond25 at gmail.com  Tue Dec  6 00:28:07 2016
From: edmond25 at gmail.com (Edmond Chu)
Date: Tue, 6 Dec 2016 16:28:07 +0800
Subject: Compile error 0.11.6
Message-ID: <CAEP_uVW+p+YQwXJULJpi0XZAQ8wZuRRV+fhx4z=07X8ABgu8NA@mail.gmail.com>

Hi,

I found an error to compile the version 0.11.6 which is no problem on
compiling 0.11.5

  AR       libopts.a
make[3]: Leaving directory `/root/ocserv-0.11.6/libopts'
make[2]: Leaving directory `/root/ocserv-0.11.6/libopts'
Making all in src
make[2]: Entering directory `/root/ocserv-0.11.6/src'
if test ":" = ":";then \
                rm -f ./ocserv-args.c; \
                rm -f ./ocserv-args.h; \
                cp ./autogen/ocserv-args.c ./; \
                cp ./autogen/ocserv-args.h ./; \
        else \
                : ocserv-args.def; \
                if test -d ./autogen;then \
                        cp ./ocserv-args.c ./autogen; \
                        cp ./ocserv-args.h ./autogen; \
                fi; \
        fi
cp: cannot stat `./autogen/ocserv-args.c': No such file or directory
cp: cannot stat `./autogen/ocserv-args.h': No such file or directory
make[2]: *** [ocserv-args.c] Error 1
make[2]: Leaving directory `/root/ocserv-0.11.6/src'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/root/ocserv-0.11.6'
make: *** [all] Error 2
[root at localhost ocserv-0.11.6]$ service ocserv start
Starting OpenConnect VPN Server Daemon: Parsing plain auth method
subconfig using legacy format
note: setting 'plain' as primary authentication method
note: setting 'file' as supplemental config option

I am using CentOS 6.5, it should be no libopts things on previously ??
and autogen things also.

how can I fix it??

Regards,
Edmond


From chris.a.libby at gmail.com  Tue Dec  6 04:37:30 2016
From: chris.a.libby at gmail.com (Chris Libby)
Date: Tue, 6 Dec 2016 07:37:30 -0500
Subject: Fwd: Prompting for username and password together
In-Reply-To: <CAB6mDFSxX8u=3V=BbigeCe_VK_zikaiuWbixg6_T86cpLUWnHA@mail.gmail.com>
References: <CAB6mDFS0PPdxcPa3fq6V-er_7hSbE8EJsZxzcrzuoA8vbP7DDQ@mail.gmail.com>
 <CAB6mDFSxX8u=3V=BbigeCe_VK_zikaiuWbixg6_T86cpLUWnHA@mail.gmail.com>
Message-ID: <CAB6mDFSqojYizUSTQxWzLSqVYskSGzufKc9zturkwzdNRgtPYQ@mail.gmail.com>

Disclaimer:  I'm a openconnect nub and probably posting to the wrong
list, so I will apologize up front if that's the case.  I did some
googling for the answers below but wasn't able to find the answers
that I have been looking for.

Two relatively quick questions:
 - Is there an easy way to force ocserv to prompt for the username and
password at the same time?
 - Is there a way to integrate DUO 2FA?

Thanks to everyone on the project for putting together such a great
package!  I was able to get up and running in less that 45 minutes on
my first try!

- Chris


From n.mavrogiannopoulos at gmail.com  Tue Dec  6 07:57:57 2016
From: n.mavrogiannopoulos at gmail.com (Nikos Mavrogiannopoulos)
Date: Tue, 6 Dec 2016 16:57:57 +0100
Subject: Compile error 0.11.6
In-Reply-To: <CAEP_uVW+p+YQwXJULJpi0XZAQ8wZuRRV+fhx4z=07X8ABgu8NA@mail.gmail.com>
References: <CAEP_uVW+p+YQwXJULJpi0XZAQ8wZuRRV+fhx4z=07X8ABgu8NA@mail.gmail.com>
Message-ID: <CAJU7za+argmQfXRnTsqZt8auBPs=+MFzQ=pfg=KBTqPvVSsFow@mail.gmail.com>

You could try the EPEL6 builds at:
http://koji.fedoraproject.org/koji/taskinfo?taskID=16773138


On Tue, Dec 6, 2016 at 9:28 AM, Edmond Chu <edmond25 at gmail.com> wrote:
> Hi,
>
> I found an error to compile the version 0.11.6 which is no problem on
> compiling 0.11.5
>
>   AR       libopts.a
> make[3]: Leaving directory `/root/ocserv-0.11.6/libopts'
> make[2]: Leaving directory `/root/ocserv-0.11.6/libopts'
> Making all in src
> make[2]: Entering directory `/root/ocserv-0.11.6/src'
> if test ":" = ":";then \
>                 rm -f ./ocserv-args.c; \
>                 rm -f ./ocserv-args.h; \
>                 cp ./autogen/ocserv-args.c ./; \
>                 cp ./autogen/ocserv-args.h ./; \
>         else \
>                 : ocserv-args.def; \
>                 if test -d ./autogen;then \
>                         cp ./ocserv-args.c ./autogen; \
>                         cp ./ocserv-args.h ./autogen; \
>                 fi; \
>         fi
> cp: cannot stat `./autogen/ocserv-args.c': No such file or directory
> cp: cannot stat `./autogen/ocserv-args.h': No such file or directory
> make[2]: *** [ocserv-args.c] Error 1
> make[2]: Leaving directory `/root/ocserv-0.11.6/src'
> make[1]: *** [all-recursive] Error 1
> make[1]: Leaving directory `/root/ocserv-0.11.6'
> make: *** [all] Error 2
> [root at localhost ocserv-0.11.6]$ service ocserv start
> Starting OpenConnect VPN Server Daemon: Parsing plain auth method
> subconfig using legacy format
> note: setting 'plain' as primary authentication method
> note: setting 'file' as supplemental config option
>
> I am using CentOS 6.5, it should be no libopts things on previously ??
> and autogen things also.
>
> how can I fix it??
>
> Regards,
> Edmond
>
> _______________________________________________
> openconnect-devel mailing list
> openconnect-devel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/openconnect-devel


From n.mavrogiannopoulos at gmail.com  Thu Dec  8 03:02:47 2016
From: n.mavrogiannopoulos at gmail.com (Nikos Mavrogiannopoulos)
Date: Thu, 8 Dec 2016 12:02:47 +0100
Subject: Prompting for username and password together
In-Reply-To: <CAB6mDFSqojYizUSTQxWzLSqVYskSGzufKc9zturkwzdNRgtPYQ@mail.gmail.com>
References: <CAB6mDFS0PPdxcPa3fq6V-er_7hSbE8EJsZxzcrzuoA8vbP7DDQ@mail.gmail.com>
 <CAB6mDFSxX8u=3V=BbigeCe_VK_zikaiuWbixg6_T86cpLUWnHA@mail.gmail.com>
 <CAB6mDFSqojYizUSTQxWzLSqVYskSGzufKc9zturkwzdNRgtPYQ@mail.gmail.com>
Message-ID: <CAJU7zaLtYWqRRejG_4aAe4BWzRg=s1SH7KSSR5uZT63XtbCWVQ@mail.gmail.com>

On Tue, Dec 6, 2016 at 1:37 PM, Chris Libby <chris.a.libby at gmail.com> wrote:
> Disclaimer:  I'm a openconnect nub and probably posting to the wrong
> list, so I will apologize up front if that's the case.  I did some
> googling for the answers below but wasn't able to find the answers
> that I have been looking for.
> Two relatively quick questions:
>  - Is there an easy way to force ocserv to prompt for the username and
> password at the same time?

No. It is designed around pam which asks one question at a time.

>  - Is there a way to integrate DUO 2FA?

I wouldn't know. It depends what interfaces the duo provides. There
were some discussions previously on this list. I think if you have a
functional pam module, it would work.

regards,
Nikos


From chris.a.libby at gmail.com  Thu Dec  8 04:32:45 2016
From: chris.a.libby at gmail.com (Chris Libby)
Date: Thu, 8 Dec 2016 07:32:45 -0500
Subject: Prompting for username and password together
In-Reply-To: <CAJU7zaLtYWqRRejG_4aAe4BWzRg=s1SH7KSSR5uZT63XtbCWVQ@mail.gmail.com>
References: <CAB6mDFS0PPdxcPa3fq6V-er_7hSbE8EJsZxzcrzuoA8vbP7DDQ@mail.gmail.com>
 <CAB6mDFSxX8u=3V=BbigeCe_VK_zikaiuWbixg6_T86cpLUWnHA@mail.gmail.com>
 <CAB6mDFSqojYizUSTQxWzLSqVYskSGzufKc9zturkwzdNRgtPYQ@mail.gmail.com>
 <CAJU7zaLtYWqRRejG_4aAe4BWzRg=s1SH7KSSR5uZT63XtbCWVQ@mail.gmail.com>
Message-ID: <CAB6mDFT_OTPcLKDG56o_Ce_agH2ZX8isEqsCZO-=QyWYdTXRPw@mail.gmail.com>

Thank you for the information.  From what I can tell, Duo uses secure
LDAP.  I'll check the docs and see what I can dredge up sometime soon.

On Thu, Dec 8, 2016 at 6:02 AM, Nikos Mavrogiannopoulos
<n.mavrogiannopoulos at gmail.com> wrote:
> On Tue, Dec 6, 2016 at 1:37 PM, Chris Libby <chris.a.libby at gmail.com> wrote:
>> Disclaimer:  I'm a openconnect nub and probably posting to the wrong
>> list, so I will apologize up front if that's the case.  I did some
>> googling for the answers below but wasn't able to find the answers
>> that I have been looking for.
>> Two relatively quick questions:
>>  - Is there an easy way to force ocserv to prompt for the username and
>> password at the same time?
>
> No. It is designed around pam which asks one question at a time.
>
>>  - Is there a way to integrate DUO 2FA?
>
> I wouldn't know. It depends what interfaces the duo provides. There
> were some discussions previously on this list. I think if you have a
> functional pam module, it would work.
>
> regards,
> Nikos


From tom at ycombinator.com  Mon Dec 12 12:43:33 2016
From: tom at ycombinator.com (Tom Sparks)
Date: Mon, 12 Dec 2016 12:43:33 -0800
Subject: Openconnect 7.07 and Pulse 8.2 not working
Message-ID: <CABLy0qRbxTGx6GdZbLPBVu0rNnUMp03dTiMkRFug_EZ4POHYZg@mail.gmail.com>

I recently upgraded from Pulse 8.1 to 8.2 and OpenConnect stopped working
for me and some of my other users. We're using FreeBSD and OSX.

Basically I get this error message:
Dec 12 10:51:03 XXXXXXX openconnect[42889]: Unexpected 400 result from
server

It looks like the URL the client needs to hit to start a network connect
session has changed and I haven't found an easy way to change that in the
client.

Has anyone else experienced or patched this?

-- 
Tom Sparks
Systems Engineer


From dwmw2 at infradead.org  Mon Dec 12 13:11:52 2016
From: dwmw2 at infradead.org (David Woodhouse)
Date: Mon, 12 Dec 2016 21:11:52 +0000
Subject: Openconnect 7.07 and Pulse 8.2 not working
In-Reply-To: <CABLy0qRbxTGx6GdZbLPBVu0rNnUMp03dTiMkRFug_EZ4POHYZg@mail.gmail.com>
References: <CABLy0qRbxTGx6GdZbLPBVu0rNnUMp03dTiMkRFug_EZ4POHYZg@mail.gmail.com>
Message-ID: <1481577112.31484.0.camel@infradead.org>

On Mon, 2016-12-12 at 12:43 -0800, Tom Sparks wrote:
> I recently upgraded from Pulse 8.1 to 8.2 and OpenConnect stopped
> working
> for me and some of my other users. We're using FreeBSD and OSX.
> 
> Basically I get this error message:
> Dec 12 10:51:03 XXXXXXX openconnect[42889]: Unexpected 400 result
> from
> server
> 
> It looks like the URL the client needs to hit to start a network
> connect
> session has changed and I haven't found an easy way to change that in
> the
> client.
> 
> Has anyone else experienced or patched this?

It's fixed in 7.08. Which I haven't released yet but really should.


From dwmw2 at infradead.org  Tue Dec 13 03:59:50 2016
From: dwmw2 at infradead.org (David Woodhouse)
Date: Tue, 13 Dec 2016 11:59:50 +0000
Subject: adding support for PAN Globalprotect (SSL+ESP) to Openconnect
In-Reply-To: <CAOw_LSHF_CXMDAtKjN9P2x3_Y7+gHi4XdXeabbUbzDaBB9CUzg@mail.gmail.com>
References: <CAOw_LSHF_CXMDAtKjN9P2x3_Y7+gHi4XdXeabbUbzDaBB9CUzg@mail.gmail.com>
Message-ID: <1481630390.98151.24.camel@infradead.org>

On Sun, 2016-11-06 at 13:55 -0800, Daniel Lenski wrote:
> As discussed last month
> (http://lists.infradead.org/pipermail/openconnect-devel/2016-October/004010.html),
> I've modified openconnect to support Globalprotect VPNs. This is an
> SSL+ESP VPN and it has been fairly straightforward to make Openconnect
> support it.
> 
> I've now been using it successfully for real work for several weeks
> and have a couple reports of successful use by others.
> 
> Is this a good point to submit patches to add GP support?
> 
> I was planning to break down my changes into two parts to make them
> easier to review. First, add *SSL-only* support for GP. This is a
> pretty self-contained change, requiring only two small patches to the
> rest of the OpenConnect code to work correctly:
> 
> - Handle IPv4 route specified as either 10.1.2.0/255.255.255.0 or 10.1.2.0/24:
>   http://lists.infradead.org/pipermail/openconnect-devel/2016-October/004039.html
> 
> - Unset got_cancel_cmd after reacting to it, as is already done for
> got_pause_cmd:
>   http://lists.infradead.org/pipermail/openconnect-devel/2016-October/004038.html

I've merged these and they'll be in the 7.08 release, which I'm working
on right now and?hoping to push?out today unless anything explodes.

I'm slightly reticent about merging new protocols but I think it makes
sense, and your submissions so far have reassured me that you'll do a
good job of maintaining it.

However, I think I do need to lumber you with an additional hurdle
before we merge your new protocol after 7.08 ? let's add a new API to
check whether libopenconnect supports a given protocol, or to enumerate
the protocols it supports. Currently it's just a hard-coded "if it's
7.05 or newer, it supports Juniper too", and I don't think we want that
to continue. Let's do something explicit instead, and things like
NetworkManager-openconnect can base their decisions on that.

-- 
dwmw2
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5760 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/openconnect-devel/attachments/20161213/d8123ee0/attachment.bin>

From dwmw2 at infradead.org  Tue Dec 13 08:28:38 2016
From: dwmw2 at infradead.org (David Woodhouse)
Date: Tue, 13 Dec 2016 16:28:38 +0000
Subject: OpenConnect 7.08 release
Message-ID: <1481646518.98151.32.camel@infradead.org>

A bunch of fixes, including Juniper compatibility with Junos Pulse 8.2
servers, and some other new form support in Juniper. We really ought to
support handling this with a 'proper' web browser, at least for the GUI
clients. The hard-coded hacks to parse known HTML forms are getting
nastier with each special case we add.

I've added a certificate torture test suite and fixed a number of the
bugs it showed with various esoteric (and not so esoteric) file
formats. Distributors, please ensure you run 'make check' in your
package build, and chase up any failures caused by the libraries you're
building against.

It supports the new DTLS 'real negotiation' support with ocserv,
instead of deciding the cipher suites in advance. And does run-time
probing for the data MTU.

Some Windows fixes, including support for point-to-point routing.

For those building against OpenSSL, this adds support for the final
OpenSSL 1.1 release. And fixes a security issue ? OpenSSL-built clients
failed to *check* that the DTLS session was actually being resumed, and
hypothetically an attacker could have captured the DTLS session by just
performing a full handshake. So the client would be exchanging IP
packets with the attacker instead of the real VPN network.

I have managed to reproduce that attack using OpenSSL-built OpenConnect
against ocserv, where it uses standard DTLS protocols. Since Cisco's
pre-1.0 version of DTLS isn't fully supported by OpenSSL for full
handshakes (it's only ever used for resumes), I wasn't trivially able
to reproduce when talking to a Cisco ASA ? but I believe it should be
possible. If you build OpenConnect against OpenSSL then you should
upgrade immediately. GnuTLS builds are not affected as they would never
succeed in performing a full negotiation in this situation anyway.

ftp://ftp.infradead.org/pub/openconnect/openconnect-7.08.tar.gz
ftp://ftp.infradead.org/pub/openconnect/openconnect-7.08.tar.gz.asc

Bj?rn Ketelaars (2):
      Fix indentation in manpage openconnect
      Small error in openconnect.8

Dan Lenski (1):
      Correctly handle IPv4 route specified as either 10.1.2.0/255.255.255.0 or 10.1.2.0/24

Daniel Lenski (3):
      append_opt() and buf_append_urlencoded() should take const char *
      Make buf_append_urlencoded() percent-encode fewer characters.
      Unset got_cancel_cmd after reacting to it, as is already done for got_pause_cmd

David Woodhouse (181):
      Handle Juniper pre-auth message too
      Revert to original OpenSSL workaround now we can access get_issuer()
      Fix OpenSSL 1.1 compiler warning
      Fix warning about unused esp_kmp_hdr in non-ESP build
      Add configure check for OpenSSL RT#4631
      Fix condition for GnuTLS ESP
      Add 1.0.1q to 1.0.1u-dev to broken OpenSSL versions (RT#4631)
      Add bad_dtls_test from OpenSSL PR#1296
      Use DTLS_client_method() and TLS_client_method() for OpenSSL 1.1+
      Fix non-const warning in legacy generate_dtls_session()
      Use X509_V_FLAG_PARTIAL_CHAIN for OpenSSL >= 1.0.2
      Kill PACKET_starts() from bad_dtls_test
      More OpenSSL 1.1 API breakage...
      Build openconnect before we test it
      Print correct filename when key not found
      Add cert format torture test
      Fix GnuTLS handling of OpenSSL encrypted PEM files
      Add support for DER-encoded PKCS#1 and PKCS#8 files with OpenSSL
      Add support for DER-encoded PKCS#1 and PKCS#8 files with GnuTLS
      Add more certificate tests: PKCs8-PBES1, and DER forms of everything
      Update changelog
      More explicit PKCS#12 tests
      Add VERBOSE=1 to gitlab make check
      Fix auth-certificate test
      Try unencrypted PKCS#8 DER specifically.
      Allow DTLS unit test to be disabled
      Use AS_HELP_STRING() consistently
      Move lzstest to tests/
      Output summary from configure script
      Only set DTLS_GNUTLS if it's true
      Fix pretty-printing of $ssl_library. "both" means we're using GnuTLS.
      Do not set HAVE_GNUTLS_SESSION_SET_PREMASTER
      Don't check for SSL_OP_CISCO_ANYCONNECT
      Instead of disabling the DTLS test, make it XFAIL
      Use oc_text_buf for constructing proxy URL
      Use oc_text_buf for constructing group-access node
      Quote SSL_DTLS_PC
      Add OpenSSL-only CI build
      Fix retry on tun fd when it isn't a Linux tun device
      Update translations from GNOME
      Resync translations with sources
      Add translations for 'Enter PKCS#8 pass phrase:'
      Add r?le selection for Juniper auth
      Fix mingw build warning
      Fix typo in r?le table matching
      Fix crash in install_extra_certs() on PKCS#12 file containing no cert
      Add newlines to PKCS#12 error messages
      Update translations from GNOME
      Add some more PKCS#12 test cases, including a mixed one that upsets GnuTLS
      Fix ESP replay integer overflow problems
      Increase ESP packet backlog to 64 packets
      Do not define _POSIX_C_SOURCE
      Include <string.h> from openconnect-internal.h
      Split ESP sequence number handling into a separate file
      Prevent ESP seq# wrap-around
      Add ESP seq# test
      Fix portability of lzstest
      Run tests even without CWRAP
      Fix up translation for ESP debug messages
      Resync translations with sources
      Update translations from GNOME
      Fix translation search/replace errors
      Disable known GnuTLS failures to make gitlab tests pass again
      Fix uninitialised variable usage in parse_roles_form_node()
      Fix FreeBSD9 build warnings
      Attempt to add FreeBSD CI build
      Fix gitlab CI config
      Slight cleanup for verify_packet_seqno
      Add --with-vpnc-script to FreeBSD CI biuld
      Run all cert tests by default with manual invocation
      Explicitly detect, and reject building with, LibreSSL
      We don't need cwrap for bad_dtls_test any more
      Add support for EC PKCS#1 certs
      Fix crash in init_esp_ciphers with OpenSSL < 1.1
      Add DSA and EC keys to torture tests
      Remove stray key files
      Make MAX definition conditional to make FreeBSD happy
      Fix main.o dependency on version.c
      Fix main.o dependency harder
      More LibreSSL build fixes
      Add missing user-cert.prm
      Use --key-password for OpenSSL PKCS#11 PIN
      Add PKCS#11 tests
      Add softhsm2.conf
      Missing auth-pkcs11
      Enable EC PKCS#11 test
      PKCS#11 test shouldn't be unconditional
      FFS, eventually I'll get the condition right
      Fix softhsm check
      Support pin-value= for PKCS#11 URI with OpenSSL
      Import keys for SoftHSM with softhsm2-util
      Re-import SoftHSM token
      Disable DSA tests for GnuTLS too
      Fix uninitialised cert pointer in load_pkcs11_certificate()
      Only run test-pkcs11 if we have cwrap
      Update changelog
      Add missing distfiles
      Change tar format to allow softhsm objects to fit
      Fix ESP replay problem
      Reorder ESP sequence checks
      Update comment
      Fix compiler warning in verify_packet_seqno()
      Fix format warning in openconnect_win32__strerror()
      Use shared runners
      Don't discard output from ocserv in tests
      Create ocserv config files from configure script
      Put test sockdir in build dir
      Add pubkey-less PKCS#11 tests
      Use --no-mark-private for all objects in token=openconnect-test1
      Add PKCS#11 test with CKA_PRIVATE on certs
      Check for errors from SSL_CTX_use_PrivateKey()
      Fix PKCS#11 error reporting
      Work around OpenSSL crash with EC keys lacking public key
      Fix OpenSSL 1.1 build of EC workaround
      Suggest using --servercert when certificate validation fails
      Kill --no-cert-check
      Call SSL_CTX_check_private_key() to validate cert+key match
      Update translations from GNOME
      Fix 'Got no issuer from PKCS#11' message
      Escape 'PKCS#11 support' in configure summary
      Remove unused variable from bad_dtls_test.c
      Fix configure reporting of Yubikey support
      Allow explicit disabling of DSA tests
      Enable CentOS CI builds
      Fix Windows inet_pton() build warning
      CI cleanups
      Revamp GnuTLS/OpenSSL detection
      Simplify ESP conditionals
      Simplify DTLS conditionals
      Remove bad-random test stuff
      Split crypto library parts out from dtls.c to {gnutls,openssl}-dtls.c
      Reinstate 'make check' warning for OpenSSL builds
      Add serverhash test tool
      Kill DTLS_FREE macro
      Fix build from clean
      Add openconnect_init_ssl() in serverhash.c
      Fix Windows build of serverhash
      Fix serverhash build with local OpenSSL
      Report actual DTLS cipher for OpenSSL
      Allow OpenSSL to use TLSv1.2
      Set SSL_OP_TLSEXT_PADDING to work around F5 firewall bugs
      Update changelog
      Update translations from GNOME
      Single pipeline for creating openconnect.8.inc
      Support --key-password for GnuTLS PKCS#11 PIN
      DTLS MTU detection fixes
      Update test suite
      Change DSA test key to 1024 bits
      Update CONFIG_STATUS_DEPENDENCIES
      Enable DSA-SHA1 in ocserv config
      Fix IPv6 setup on Solaris
      Update changelog
      Fix 'make install' from clean too.
      Add DTLS files back to translation
      Update translations from GNOME
      Explicitly disallow non-resumed sessions for legacy DTLS establishment
      Add session resume check for GnuTLS too
      Attempt to re-open CONIN$ if stdin has been redirected on Windows
      Limit netmask on Windows TAP setup to 255.255.255.254
      Remember the X-CSTP-Base-MTU: value that the server sends back
      Add GNUTLS_NO_EXTENSIONS to DTLS setup
      Better attempt at handling TAP-Windows tun setup
      Add TUNIDX for Windows vpnc-script
      Increase oNCP configuration buffer size
      Update changelog
      Update translations from GNOME
      Fix pcsclite dependency in openconnect.pc
      Fix openssl dependency in openssl.pc
      Remove unused LIBS/CFLAGS manipulation in configure.ac
      Update translations from GNOME
      Update translations from GNOME
      Enable DHE ciphers for Cisco DTLS
      Don't resume OpenSSL DTLS session for PSK-NEGOTIATE
      Allow DTLS version negotiation with PSK-NEGOTIATE and OpenSSL 1.0.2
      Calculate MTU for PSK-NEGOTIATE
      Add TPM documentation
      Changelog entry for SHA256 hashes
      Stop using deprecated LZ4 functions
      Update translations from GNOME
      Resync translations with sources
      Tag version 7.08

Jon DeVree (1):
      Add Content-Length header to mimic official pulse client

Mathias Schuepany (1):
      Patch for servers that do not listen on TCP 443

Nikolay Martynov (1):
      IPv6 packet size field doesn't include header size, take this into account

Nikos Mavrogiannopoulos (8):
      Always calculate the base_mtu value
      Indicate the the --mtu option is used by legacy servers only
      Extended MTU discovery to work even when compiled with openssl
      Enable DTLS protocol negotiation
      Introduce SHA2-256 as a peer certificate hash and make it the default
      openconnect_check_peer_cert_hash: allow partial server hash matches
      Introduced buf_append_hex()
      tests: added check for operation under different --servercert parameters

Piotr Kubaj (1):
      Fix build with LibreSSL.

Ralph Schmieder (1):
      Add --passtos option to copy TOS/TCLASS from VPN packets

Thorsten Bonhagen (1):
      gnutls GNUTLS_E_INTERRUPTED same behavior as GNUTLS_E_AGAIN

-- 
dwmw2
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5760 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/openconnect-devel/attachments/20161213/38264df6/attachment-0001.bin>

From mtmiller at debian.org  Tue Dec 13 12:02:56 2016
From: mtmiller at debian.org (Mike Miller)
Date: Tue, 13 Dec 2016 12:02:56 -0800
Subject: OpenConnect 7.08 release
In-Reply-To: <1481646518.98151.32.camel@infradead.org>
References: <1481646518.98151.32.camel@infradead.org>
Message-ID: <20161213200256.ylrqlfmaxshbectf@galago.mtmxr.com>

On Tue, Dec 13, 2016 at 16:28:38 +0000, David Woodhouse wrote:
> I've added a certificate torture test suite and fixed a number of the
> bugs it showed with various esoteric (and not so esoteric) file
> formats. Distributors, please ensure you run 'make check' in your
> package build, and chase up any failures caused by the libraries you're
> building against.

I am unable to get `auth-pkcs11` to pass. The first problem is the
hardcoded Fedora path in tests/.config/pkcs11/modules/softhsm2.module.

After fixing that for my system (/usr/lib/softhsm/libsofthsm2.so), the
test fails with:

Testing PKCS#11 auth... 
warning: skipping unknown option 'cookie-validity'
Parsing plain auth method subconfig using legacy format
note: setting 'certificate+plain' as primary authentication method
note: setting 'file' as supplemental config option
listening (TCP) on 0.0.0.0:443...
listening (TCP) on [::]:443...
listening (UDP) on 0.0.0.0:443...
listening (UDP) on [::]:443...
ocserv[14837]: main: not using control unix socket
ocserv[14837]: main: initialized ocserv 0.11.6
ocserv[14847]: sec-mod: reading supplemental config from files
ocserv[14847]: sec-mod: sec-mod initialized (socket: ./ocserv-socket.14837)
ocserv[14837]: main: processed 1 CA certificate(s)
Connecting to obtain cookie (token openconnect-test key object=RSA)... error in setrlimit(1024): Operation not permitted
p11-kit: softhsm2: module failed to initialize, skipping: Internal error
Error loading certificate from PKCS#11: The requested data were not available.
Loading certificate failed. Aborting.
Failed to open HTTPS connection to 127.0.0.2
Failed to obtain WebVPN cookie
ocserv[14920]: GnuTLS error (at worker-vpn.c:595): The TLS connection was non-properly terminated.
ocserv[14837]: main: 127.0.0.2:24871 user disconnected (reason: unspecified, rx: 0, tx: 0)
Failure: Could not connect with token openconnect-test key object=RSA!
ocserv[14837]: main: termination request received; waiting for children to die
FAIL auth-pkcs11 (exit status: 1)

I'm happy to run more tests if there is something worth debugging here,
but I don't know what to look at.

-- 
mike


From dwmw2 at infradead.org  Tue Dec 13 14:07:31 2016
From: dwmw2 at infradead.org (David Woodhouse)
Date: Tue, 13 Dec 2016 22:07:31 +0000
Subject: OpenConnect 7.08 release
In-Reply-To: <20161213200256.ylrqlfmaxshbectf@galago.mtmxr.com>
References: <1481646518.98151.32.camel@infradead.org>
 <20161213200256.ylrqlfmaxshbectf@galago.mtmxr.com>
Message-ID: <1481666851.98151.42.camel@infradead.org>

On Tue, 2016-12-13 at 12:02 -0800, Mike Miller wrote:
> On Tue, Dec 13, 2016 at 16:28:38 +0000, David Woodhouse wrote:
> > I've added a certificate torture test suite and fixed a number of the
> > bugs it showed with various esoteric (and not so esoteric) file
> > formats. Distributors, please ensure you run 'make check' in your
> > package build, and chase up any failures caused by the libraries you're
> > building against.
> 
> I am unable to get `auth-pkcs11` to pass. The first problem is the
> hardcoded Fedora path in tests/.config/pkcs11/modules/softhsm2.module.

We might do better on IRC to work through this...

Is SoftHSM installed correctly with a p11-kit .module file in
/usr/share/p11-kit/modules/softhsm.module (or I suppose that should be
$(pkgconfig --variable=p11_module_configs p11-kit-1)/softhsm.module ? 

If not, we probably want to file a bug against it because it won't show
up in applications by default.

> After fixing that for my system (/usr/lib/softhsm/libsofthsm2.so), the
> test fails with:
> 
> Connecting to obtain cookie (token openconnect-test key object=RSA)... error in setrlimit(1024): Operation not permitted
> p11-kit: softhsm2: module failed to initialize, skipping: Internal error
> Error loading certificate from PKCS#11: The requested data were not available.

Hm, is SoftHSM working at all, as packaged? Is it the setrlimit which
is causing a hard failure, or something else?

-- 
dwmw2
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5760 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/openconnect-devel/attachments/20161213/b676aa51/attachment.bin>

From dwmw2 at infradead.org  Tue Dec 13 14:17:48 2016
From: dwmw2 at infradead.org (David Woodhouse)
Date: Tue, 13 Dec 2016 22:17:48 +0000
Subject: OpenConnect 7.08 release
In-Reply-To: <1481666851.98151.42.camel@infradead.org>
References: <1481646518.98151.32.camel@infradead.org>
 <20161213200256.ylrqlfmaxshbectf@galago.mtmxr.com>
 <1481666851.98151.42.camel@infradead.org>
Message-ID: <1481667468.98151.44.camel@infradead.org>

On Tue, 2016-12-13 at 22:07 +0000, David Woodhouse wrote:
> 
> We might do better on IRC to work through this...
> 
> Is SoftHSM installed correctly with a p11-kit .module file in
> /usr/share/p11-kit/modules/softhsm.module (or I suppose that should be
> $(pkgconfig --variable=p11_module_configs p11-kit-1)/softhsm.module ? 
> 
> If not, we probably want to file a bug against it because it won't show
> up in applications by default.

For me it also suffers from 
https://bugs.launchpad.net/ubuntu/+source/p11-kit/+bug/1648634 and the
final problem is that it doesn't seem to honour the $SOFTHSM2_CONF
environment variable, and looks in $HOME/.config/softhsm2/softhsm2.conf
(where $HOME is pointing into the openconnect tree for the tests).

After that it works for me.

Can I leave you to work out what needs fixing in the packaging of
SoftHSM and what needs fixing in OpenConnect?

-- 
dwmw2
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5760 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/openconnect-devel/attachments/20161213/43ec4e78/attachment.bin>

From mtmiller at debian.org  Tue Dec 13 14:42:56 2016
From: mtmiller at debian.org (Mike Miller)
Date: Tue, 13 Dec 2016 14:42:56 -0800
Subject: OpenConnect 7.08 release
In-Reply-To: <1481667468.98151.44.camel@infradead.org>
References: <1481646518.98151.32.camel@infradead.org>
 <20161213200256.ylrqlfmaxshbectf@galago.mtmxr.com>
 <1481666851.98151.42.camel@infradead.org>
 <1481667468.98151.44.camel@infradead.org>
Message-ID: <20161213224256.gomaepr2fan7ym6e@galago.mtmxr.com>

On Tue, Dec 13, 2016 at 22:17:48 +0000, David Woodhouse wrote:
> For me it also suffers from 
> https://bugs.launchpad.net/ubuntu/+source/p11-kit/+bug/1648634 and the
> final problem is that it doesn't seem to honour the $SOFTHSM2_CONF
> environment variable, and looks in $HOME/.config/softhsm2/softhsm2.conf
> (where $HOME is pointing into the openconnect tree for the tests).
> 
> After that it works for me.

Wow, thanks, after simply copying tests/softhsm2.conf to
tests/.config/softhsm2/softhsm2.conf the test passes. Good find, I was
not seeing this in my strace for some reason.

Would you be open to using .config/softhsm2 upstream or do you want to
keep using the environment variable?

Any thoughts about how to make the contents of softhsm2.module more
distro-agnostic?

Btw, the setrlimit error was on the ocserv side, and can be safely
ignored, at least for the purposes of this test suite.

> Can I leave you to work out what needs fixing in the packaging of
> SoftHSM and what needs fixing in OpenConnect?

Sure, I'm not directly involved, but I'll try to push for some fixes for
these configuration issues.

-- 
mike


From dwmw2 at infradead.org  Tue Dec 13 14:50:55 2016
From: dwmw2 at infradead.org (David Woodhouse)
Date: Tue, 13 Dec 2016 22:50:55 +0000
Subject: OpenConnect 7.08 release
In-Reply-To: <20161213224256.gomaepr2fan7ym6e@galago.mtmxr.com>
References: <1481646518.98151.32.camel@infradead.org>
 <20161213200256.ylrqlfmaxshbectf@galago.mtmxr.com>
 <1481666851.98151.42.camel@infradead.org>
 <1481667468.98151.44.camel@infradead.org>
 <20161213224256.gomaepr2fan7ym6e@galago.mtmxr.com>
Message-ID: <1481669455.98151.47.camel@infradead.org>

On Tue, 2016-12-13 at 14:42 -0800, Mike Miller wrote:
> Wow, thanks, after simply copying tests/softhsm2.conf to
> tests/.config/softhsm2/softhsm2.conf the test passes. Good find, I was
> not seeing this in my strace for some reason.
> 
> Would you be open to using .config/softhsm2 upstream or do you want to
> keep using the environment variable?

Hm, I'm not convinced that $HOME/.config/softhsm2/ thing is upstream;
is it a Debian patch?

It makes some sense; get it upstream and I'll chase it into Fedora too.

I suppose putting it in $HOME/.config/softhsm2/ and then using the
(upstream) SOFTHSM2_CONF environment variable to point to the same
place should work for everyone, and I can't see a problem with that in
the short term.

Why *doesn't* the Debian package honour $SOFTHSM2_CONF though?

> Any thoughts about how to make the contents of softhsm2.module more
> distro-agnostic?

Build it (from the distro's own one) at configure time? We already
build softhsm2.conf from softhsm2.conf.in anyway.

> Btw, the setrlimit error was on the ocserv side, and can be safely
> ignored, at least for the purposes of this test suite.

OK.

> > Can I leave you to work out what needs fixing in the packaging of
> > SoftHSM and what needs fixing in OpenConnect?
> 
> Sure, I'm not directly involved, but I'll try to push for some fixes for
> these configuration issues.

Thanks.

Might be worth keeping an eye on this one which bites OpenConnect too:
https://bugs.launchpad.net/ubuntu/+source/gnutls28/+bug/1649270

-- 
dwmw2
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5760 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/openconnect-devel/attachments/20161213/0664c0d3/attachment.bin>

From mtmiller at debian.org  Tue Dec 13 14:58:46 2016
From: mtmiller at debian.org (Mike Miller)
Date: Tue, 13 Dec 2016 14:58:46 -0800
Subject: OpenConnect 7.08 release
In-Reply-To: <1481669455.98151.47.camel@infradead.org>
References: <1481646518.98151.32.camel@infradead.org>
 <20161213200256.ylrqlfmaxshbectf@galago.mtmxr.com>
 <1481666851.98151.42.camel@infradead.org>
 <1481667468.98151.44.camel@infradead.org>
 <20161213224256.gomaepr2fan7ym6e@galago.mtmxr.com>
 <1481669455.98151.47.camel@infradead.org>
Message-ID: <20161213225846.nvob5qwbmdrzy5om@galago.mtmxr.com>

On Tue, Dec 13, 2016 at 22:50:55 +0000, David Woodhouse wrote:
> Why *doesn't* the Debian package honour $SOFTHSM2_CONF though?

Ok, it does, it's actually because the environment variable isn't being
passed to ocserv (and probably because the permissions on /etc/softhsm2
are wrong in Debian). The following fully fixes this for me


>From e26a4e19f528439fe7f02890d5bfe695365c3e9b Mon Sep 17 00:00:00 2001
From: Mike Miller <mtmiller at debian.org>
Date: Tue, 13 Dec 2016 14:51:28 -0800
Subject: [PATCH] Ensure full test suite uses local softhsm2.conf

Add SOFTHSM2_CONF to the test environment so it is picked up by both
ocserv and openconnect when needed.

Signed-off-by: Mike Miller <mtmiller at debian.org>
---
 tests/auth-pkcs11 | 2 +-
 tests/common.sh   | 1 +
 2 files changed, 2 insertions(+), 1 deletion(-)

diff --git a/tests/auth-pkcs11 b/tests/auth-pkcs11
index adc40f5..ee6dc5a 100755
--- a/tests/auth-pkcs11
+++ b/tests/auth-pkcs11
@@ -36,7 +36,7 @@ for TOKEN in ${pkcs11_tokens}; do
     for KEY in ${pkcs11_keys}; do
 	echo -n "Connecting to obtain cookie (token ${TOKEN} key ${KEY})... "
 	CERTURI="pkcs11:token=${TOKEN};${KEY};pin-value=1234"
-	( echo "test" | HOME=${srcdir} SOFTHSM2_CONF=softhsm2.conf LD_PRELOAD=libsocket_wrapper.so \
+	( echo "test" | HOME=${srcdir} LD_PRELOAD=libsocket_wrapper.so \
 			    $OPENCONNECT -q $ADDRESS:443 -u test -c \"${CERTURI}\" --key-password 1234 --servercert=d66b507ae074d03b02eafca40d35f87dd81049d3 --cookieonly --passwd-on-stdin ) ||
 	    fail $PID "Could not connect with token ${TOKEN} key ${KEY##*/}!"
     done
diff --git a/tests/common.sh b/tests/common.sh
index d89cf83..c88954c 100644
--- a/tests/common.sh
+++ b/tests/common.sh
@@ -30,6 +30,7 @@ SOCKDIR="./sockwrap.$$.tmp"
 mkdir -p $SOCKDIR
 export SOCKET_WRAPPER_DIR=$SOCKDIR
 export SOCKET_WRAPPER_DEFAULT_IFACE=2
+export SOFTHSM2_CONF=softhsm2.conf
 ADDRESS=127.0.0.$SOCKET_WRAPPER_DEFAULT_IFACE
 OPENCONNECT="eval LD_PRELOAD=libsocket_wrapper.so ${top_builddir}/openconnect"
 
-- 
2.10.2

-- 
mike


From dwmw2 at infradead.org  Tue Dec 13 15:00:33 2016
From: dwmw2 at infradead.org (David Woodhouse)
Date: Tue, 13 Dec 2016 23:00:33 +0000
Subject: OpenConnect 7.08 release
In-Reply-To: <20161213225846.nvob5qwbmdrzy5om@galago.mtmxr.com>
References: <1481646518.98151.32.camel@infradead.org>
 <20161213200256.ylrqlfmaxshbectf@galago.mtmxr.com>
 <1481666851.98151.42.camel@infradead.org>
 <1481667468.98151.44.camel@infradead.org>
 <20161213224256.gomaepr2fan7ym6e@galago.mtmxr.com>
 <1481669455.98151.47.camel@infradead.org>
 <20161213225846.nvob5qwbmdrzy5om@galago.mtmxr.com>
Message-ID: <1481670033.98151.48.camel@infradead.org>

On Tue, 2016-12-13 at 14:58 -0800, Mike Miller wrote:
> Ok, it does, it's actually because the environment variable isn't being
> passed to ocserv (and probably because the permissions on /etc/softhsm2
> are wrong in Debian). The following fully fixes this for me

But ocserv isn't even *using* SoftHSM. Is it failing to start up purely
because SoftHSM is broken?

-- 
dwmw2
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5760 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/openconnect-devel/attachments/20161213/f5921fbf/attachment.bin>

From mtmiller at debian.org  Tue Dec 13 15:32:34 2016
From: mtmiller at debian.org (Mike Miller)
Date: Tue, 13 Dec 2016 15:32:34 -0800
Subject: OpenConnect 7.08 release
In-Reply-To: <1481670033.98151.48.camel@infradead.org>
References: <1481646518.98151.32.camel@infradead.org>
 <20161213200256.ylrqlfmaxshbectf@galago.mtmxr.com>
 <1481666851.98151.42.camel@infradead.org>
 <1481667468.98151.44.camel@infradead.org>
 <20161213224256.gomaepr2fan7ym6e@galago.mtmxr.com>
 <1481669455.98151.47.camel@infradead.org>
 <20161213225846.nvob5qwbmdrzy5om@galago.mtmxr.com>
 <1481670033.98151.48.camel@infradead.org>
Message-ID: <20161213233234.gyfeakgdr6baxnyr@galago.mtmxr.com>

On Tue, Dec 13, 2016 at 22:50:55 +0000, David Woodhouse wrote:
> On Tue, 2016-12-13 at 14:42 -0800, Mike Miller wrote:
> > Any thoughts about how to make the contents of softhsm2.module more
> > distro-agnostic?
> 
> Build it (from the distro's own one) at configure time? We already
> build softhsm2.conf from softhsm2.conf.in anyway.

Sorry, I was jumping back to the .module file here, not the .conf file.

The softhsm2.module file in the release has a hardcoded path to
/usr/lib64. It's a one-liner and easy enough to overwrite here, but will
probably trip up others too.


On Tue, Dec 13, 2016 at 23:00:33 +0000, David Woodhouse wrote:
> But ocserv isn't even *using* SoftHSM. Is it failing to start up purely
> because SoftHSM is broken?

Sorry, you're right, it doesn't have to be in ocserv's environment, that
was a bad assumption on my part, but something about the way that
command line is constructed is not working here. I don't know what the
difference here is, but this patch also fixes it for me


>From 780a9b35fd7a9a4ec162db972591a236a33ee142 Mon Sep 17 00:00:00 2001
From: Mike Miller <mtmiller at debian.org>
Date: Tue, 13 Dec 2016 14:51:28 -0800
Subject: [PATCH] Ensure test suite uses local softhsm2.conf

Add SOFTHSM2_CONF to the test environment so it is picked up by
openconnect.

Signed-off-by: Mike Miller <mtmiller at debian.org>
---
 tests/auth-pkcs11 | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/tests/auth-pkcs11 b/tests/auth-pkcs11
index adc40f5..230b800 100755
--- a/tests/auth-pkcs11
+++ b/tests/auth-pkcs11
@@ -36,7 +36,8 @@ for TOKEN in ${pkcs11_tokens}; do
     for KEY in ${pkcs11_keys}; do
 	echo -n "Connecting to obtain cookie (token ${TOKEN} key ${KEY})... "
 	CERTURI="pkcs11:token=${TOKEN};${KEY};pin-value=1234"
-	( echo "test" | HOME=${srcdir} SOFTHSM2_CONF=softhsm2.conf LD_PRELOAD=libsocket_wrapper.so \
+	export SOFTHSM2_CONF=softhsm2.conf
+	( echo "test" | HOME=${srcdir} LD_PRELOAD=libsocket_wrapper.so \
 			    $OPENCONNECT -q $ADDRESS:443 -u test -c \"${CERTURI}\" --key-password 1234 --servercert=d66b507ae074d03b02eafca40d35f87dd81049d3 --cookieonly --passwd-on-stdin ) ||
 	    fail $PID "Could not connect with token ${TOKEN} key ${KEY##*/}!"
     done
-- 
2.10.2

-- 
mike


From mtmiller at debian.org  Tue Dec 13 15:46:41 2016
From: mtmiller at debian.org (Mike Miller)
Date: Tue, 13 Dec 2016 15:46:41 -0800
Subject: OpenConnect 7.08 release
In-Reply-To: <20161213233234.gyfeakgdr6baxnyr@galago.mtmxr.com>
References: <1481646518.98151.32.camel@infradead.org>
 <20161213200256.ylrqlfmaxshbectf@galago.mtmxr.com>
 <1481666851.98151.42.camel@infradead.org>
 <1481667468.98151.44.camel@infradead.org>
 <20161213224256.gomaepr2fan7ym6e@galago.mtmxr.com>
 <1481669455.98151.47.camel@infradead.org>
 <20161213225846.nvob5qwbmdrzy5om@galago.mtmxr.com>
 <1481670033.98151.48.camel@infradead.org>
 <20161213233234.gyfeakgdr6baxnyr@galago.mtmxr.com>
Message-ID: <20161213234641.zidzatui3alhrndw@galago.mtmxr.com>

On Tue, Dec 13, 2016 at 15:32:34 -0800, Mike Miller wrote:
> Sorry, you're right, it doesn't have to be in ocserv's environment, that
> was a bad assumption on my part, but something about the way that
> command line is constructed is not working here. I don't know what the
> difference here is, but this patch also fixes it for me

Ok, this comes down to dash vs bash as /bin/sh. Something about this
script isn't playing right in dash, so either this patch, or changing
the shebang to /bin/bash also works.

-- 
mike


From dwmw2 at infradead.org  Wed Dec 14 00:36:56 2016
From: dwmw2 at infradead.org (David Woodhouse)
Date: Wed, 14 Dec 2016 08:36:56 +0000
Subject: OpenConnect 7.08 release
In-Reply-To: <20161213233234.gyfeakgdr6baxnyr@galago.mtmxr.com>
References: <1481646518.98151.32.camel@infradead.org>
 <20161213200256.ylrqlfmaxshbectf@galago.mtmxr.com>
 <1481666851.98151.42.camel@infradead.org>
 <1481667468.98151.44.camel@infradead.org>
 <20161213224256.gomaepr2fan7ym6e@galago.mtmxr.com>
 <1481669455.98151.47.camel@infradead.org>
 <20161213225846.nvob5qwbmdrzy5om@galago.mtmxr.com>
 <1481670033.98151.48.camel@infradead.org>
 <20161213233234.gyfeakgdr6baxnyr@galago.mtmxr.com>
Message-ID: <1481704616.4156.8.camel@infradead.org>

On Tue, 2016-12-13 at 15:32 -0800, Mike Miller wrote:
> On Tue, Dec 13, 2016 at 22:50:55 +0000, David Woodhouse wrote:
> > 
> > On Tue, 2016-12-13 at 14:42 -0800, Mike Miller wrote:
> > > 
> > > Any thoughts about how to make the contents of softhsm2.module more
> > > distro-agnostic?
> > Build it (from the distro's own one) at configure time? We already
> > build softhsm2.conf from softhsm2.conf.in anyway.
>
> Sorry, I was jumping back to the .module file here, not the .conf file.
> 
> The softhsm2.module file in the release has a hardcoded path to
> /usr/lib64. It's a one-liner and easy enough to overwrite here, but will
> probably trip up others too.

Right. I was saying that we already create the .conf file at configure
time, so we could create the .module file then too.

But then again... why? My proposal for discovering where SoftHSM2
resides was just to look for an existing p11-kit module file in the
system's configuration. And if we're going to require that the distro's
packaging of SoftHSM is correct and installs it with a p11-kit .module
file... then why do we need to bother messing with $HOME and providing
our own in the first place?

Let's just drop the whole nonsense and rely on the system packaging
SoftHSM2 correctly. Does that seem reasonable? I suppose we could also
add a --with-softhsm2= configure argument, but I'd prefer not to.


> --- a/tests/auth-pkcs11
> +++ b/tests/auth-pkcs11
> @@ -36,7 +36,8 @@ for TOKEN in ${pkcs11_tokens}; do
> ?????for KEY in ${pkcs11_keys}; do
> ?	echo -n "Connecting to obtain cookie (token ${TOKEN} key ${KEY})... "
> ?	CERTURI="pkcs11:token=${TOKEN};${KEY};pin-value=1234"
> -	( echo "test" | HOME=${srcdir} SOFTHSM2_CONF=softhsm2.conf LD_PRELOAD=libsocket_wrapper.so \
> +	export SOFTHSM2_CONF=softhsm2.conf
> +	( echo "test" | HOME=${srcdir} LD_PRELOAD=libsocket_wrapper.so \

Without a comment explaining why it's done, that *is* going to get
broken again in future. And I'm confused ? what *is* the requirement?
It can't be that dash doesn't let you set more than one environment
variable at a time in the command line before the executable, because
it's still setting both $HOME and $LD_PRELOAD. So what's going on? I'd
quite like to see an explicit reference here to either the POSIX shell
specification, or a filed dash bug.



From dwmw2 at infradead.org  Wed Dec 14 05:15:15 2016
From: dwmw2 at infradead.org (David Woodhouse)
Date: Wed, 14 Dec 2016 13:15:15 +0000
Subject: Fwd: [PATCH] Add support for systemd-resolved
In-Reply-To: <CAAq2XdqwUSJ2pPTewLGi3t-a_m-r6BcsuW1sj6ckuQbvRLgm9w@mail.gmail.com>
References: <3860861501796106017@unknownmsgid>
 <CAAq2XdqwUSJ2pPTewLGi3t-a_m-r6BcsuW1sj6ckuQbvRLgm9w@mail.gmail.com>
Message-ID: <1481721315.98151.52.camel@infradead.org>

On Thu, 2016-10-20 at 02:03 -0300, Thiago Padilha wrote:
> Add support for modifying DNS information on systems using systemd-resolved. The
> communication with systemd-resolved is done through dbus, which is possible with
> the `busctl` program that comes with systemd version 229 and later.
> 
> Signed-off-by: Thiago de Arruda <tpadilha84 at gmail.com>

Applied; thanks.

-- 
dwmw2
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5760 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/openconnect-devel/attachments/20161214/c0b38e5e/attachment.bin>

From mtmiller at debian.org  Wed Dec 14 10:02:13 2016
From: mtmiller at debian.org (Mike Miller)
Date: Wed, 14 Dec 2016 10:02:13 -0800
Subject: OpenConnect 7.08 release
In-Reply-To: <1481704616.4156.8.camel@infradead.org>
References: <1481646518.98151.32.camel@infradead.org>
 <20161213200256.ylrqlfmaxshbectf@galago.mtmxr.com>
 <1481666851.98151.42.camel@infradead.org>
 <1481667468.98151.44.camel@infradead.org>
 <20161213224256.gomaepr2fan7ym6e@galago.mtmxr.com>
 <1481669455.98151.47.camel@infradead.org>
 <20161213225846.nvob5qwbmdrzy5om@galago.mtmxr.com>
 <1481670033.98151.48.camel@infradead.org>
 <20161213233234.gyfeakgdr6baxnyr@galago.mtmxr.com>
 <1481704616.4156.8.camel@infradead.org>
Message-ID: <20161214180213.vyjj3frltn4wczvk@galago.mtmxr.com>

On Wed, Dec 14, 2016 at 08:36:56 +0000, David Woodhouse wrote:
> Right. I was saying that we already create the .conf file at configure
> time, so we could create the .module file then too.
> 
> But then again... why? My proposal for discovering where SoftHSM2
> resides was just to look for an existing p11-kit module file in the
> system's configuration. And if we're going to require that the distro's
> packaging of SoftHSM is correct and installs it with a p11-kit .module
> file... then why do we need to bother messing with $HOME and providing
> our own in the first place?
> 
> Let's just drop the whole nonsense and rely on the system packaging
> SoftHSM2 correctly. Does that seem reasonable? I suppose we could also
> add a --with-softhsm2= configure argument, but I'd prefer not to.

Ok, I'll workaround locally for now and work to get the softhsm2 package
to pick up the slack.

> Without a comment explaining why it's done, that *is* going to get
> broken again in future. And I'm confused ? what *is* the requirement?
> It can't be that dash doesn't let you set more than one environment
> variable at a time in the command line before the executable, because
> it's still setting both $HOME and $LD_PRELOAD. So what's going on? I'd
> quite like to see an explicit reference here to either the POSIX shell
> specification, or a filed dash bug.

The OPENCONNECT variable contains eval. According to POSIX, variable
assignments before a special built-in utility are made in the shell
environment, and are not necessarily exported to the enviroment of the
command.

When running this script

    #!/bin/sh
    checkenv() {
      env | egrep "^(A|B|C|D|E)="
    }
    A=foo; export A
    A=bar B=bar C=bar eval "D=bar E=bar checkenv"
    echo "In the shell, A=$A, B=$B, C=$C"

under bash, checkenv has A through E in its environment, and only A is
still in the shell's environment at the end with its original value.
This looks correct if you assume that eval is handled like any command.

In mksh, checkenv has A, D, and E in its environment, and the
assignments of A, B, and C persist in the shell (with only A marked as
exported). This looks correct according to the POSIX rules for special
built-in commands.

In dash, checkenv has only A in its environment. That it is missing D
and E may be a dash bug. The assignments of A, B, and C persist in the
shell as with mksh.

It looks like the safest option is to either declare these as bash
scripts, or to avoid any mixing of variable assignments and eval
commands. In fact, every openconnect call already has LD_PRELOAD on its
command line, so the "eval LD_PRELOAD=..." is redundant at this point.

Does this patch and commit message work better for you?


>From 6174d9063979e798d15c28049bf1b472cebec284 Mon Sep 17 00:00:00 2001
From: Mike Miller <mtmiller at debian.org>
Date: Wed, 14 Dec 2016 09:48:44 -0800
Subject: [PATCH] tests: avoid using eval with variable assignments

For shell portability, avoid using eval with variable assignments to set
openconnect's environment. Shell implementations vary on whether
variable assignments in front of eval are marked as environment
variables or just treated as ordinary shell assignments.

Every call to $OPENCONNECT already has LD_PRELOAD=libsocket_wrapper.so
in front of it, so the "eval LD_PRELOAD=libsocket_wrapper.so" was
redundant anyway.

Signed-off-by: Mike Miller <mtmiller at debian.org>
---
 tests/auth-pkcs11 | 2 +-
 tests/common.sh   | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/tests/auth-pkcs11 b/tests/auth-pkcs11
index adc40f5..5e9bab7 100755
--- a/tests/auth-pkcs11
+++ b/tests/auth-pkcs11
@@ -37,7 +37,7 @@ for TOKEN in ${pkcs11_tokens}; do
 	echo -n "Connecting to obtain cookie (token ${TOKEN} key ${KEY})... "
 	CERTURI="pkcs11:token=${TOKEN};${KEY};pin-value=1234"
 	( echo "test" | HOME=${srcdir} SOFTHSM2_CONF=softhsm2.conf LD_PRELOAD=libsocket_wrapper.so \
-			    $OPENCONNECT -q $ADDRESS:443 -u test -c \"${CERTURI}\" --key-password 1234 --servercert=d66b507ae074d03b02eafca40d35f87dd81049d3 --cookieonly --passwd-on-stdin ) ||
+			    $OPENCONNECT -q $ADDRESS:443 -u test -c "${CERTURI}" --key-password 1234 --servercert=d66b507ae074d03b02eafca40d35f87dd81049d3 --cookieonly --passwd-on-stdin ) ||
 	    fail $PID "Could not connect with token ${TOKEN} key ${KEY##*/}!"
     done
 done
diff --git a/tests/common.sh b/tests/common.sh
index d89cf83..6d5736a 100644
--- a/tests/common.sh
+++ b/tests/common.sh
@@ -31,7 +31,7 @@ mkdir -p $SOCKDIR
 export SOCKET_WRAPPER_DIR=$SOCKDIR
 export SOCKET_WRAPPER_DEFAULT_IFACE=2
 ADDRESS=127.0.0.$SOCKET_WRAPPER_DEFAULT_IFACE
-OPENCONNECT="eval LD_PRELOAD=libsocket_wrapper.so ${top_builddir}/openconnect"
+OPENCONNECT="${top_builddir}/openconnect"
 
 certdir="${srcdir}/certs"
 confdir="${srcdir}/configs"
-- 
2.10.2

-- 
mike


From dwmw2 at infradead.org  Wed Dec 14 12:26:38 2016
From: dwmw2 at infradead.org (David Woodhouse)
Date: Wed, 14 Dec 2016 20:26:38 +0000
Subject: OpenConnect 7.08 release
In-Reply-To: <20161214180213.vyjj3frltn4wczvk@galago.mtmxr.com>
References: <1481646518.98151.32.camel@infradead.org>
 <20161213200256.ylrqlfmaxshbectf@galago.mtmxr.com>
 <1481666851.98151.42.camel@infradead.org>
 <1481667468.98151.44.camel@infradead.org>
 <20161213224256.gomaepr2fan7ym6e@galago.mtmxr.com>
 <1481669455.98151.47.camel@infradead.org>
 <20161213225846.nvob5qwbmdrzy5om@galago.mtmxr.com>
 <1481670033.98151.48.camel@infradead.org>
 <20161213233234.gyfeakgdr6baxnyr@galago.mtmxr.com>
 <1481704616.4156.8.camel@infradead.org>
 <20161214180213.vyjj3frltn4wczvk@galago.mtmxr.com>
Message-ID: <1481747198.98151.58.camel@infradead.org>

On Wed, 2016-12-14 at 10:02 -0800, Mike Miller wrote:
> On Wed, Dec 14, 2016 at 08:36:56 +0000, David Woodhouse wrote:
> > Right. I was saying that we already create the .conf file at configure
> > time, so we could create the .module file then too.
> > 
> > But then again... why? My proposal for discovering where SoftHSM2
> > resides was just to look for an existing p11-kit module file in the
> > system's configuration. And if we're going to require that the distro's
> > packaging of SoftHSM is correct and installs it with a p11-kit .module
> > file... then why do we need to bother messing with $HOME and providing
> > our own in the first place?
> > 
> > Let's just drop the whole nonsense and rely on the system packaging
> > SoftHSM2 correctly. Does that seem reasonable? I suppose we could also
> > add a --with-softhsm2= configure argument, but I'd prefer not to.
> 
> Ok, I'll workaround locally for now and work to get the softhsm2 package
> to pick up the slack.

OK. I think I'll rip out the local .module file completely and just
rely on SoftHSM being installed correctly ? or the user running the
tests having installed their own .module file to work around system
packaging if not.

> Does this patch and commit message work better for you?

Much better; thanks.

-- 
dwmw2
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5760 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/openconnect-devel/attachments/20161214/a4ff438a/attachment.bin>

From dwmw2 at infradead.org  Thu Dec 15 00:39:22 2016
From: dwmw2 at infradead.org (David Woodhouse)
Date: Thu, 15 Dec 2016 08:39:22 +0000
Subject: OpenConnect 7.08 release: Goodbye --no-cert-check
In-Reply-To: <1481646518.98151.32.camel@infradead.org>
References: <1481646518.98151.32.camel@infradead.org>
Message-ID: <1481791162.98151.63.camel@infradead.org>

One more thing I forgot to mention: We killed --no-cert-check.

There is no good justification for completely disabling the
authenticity checks when connecting to a server ? even if you want it
for testing purposes, that's not a good enough justification for making
this option available in the general case for na?ve users to shoot
themselves in the foot with it.

I saw advice to use --no-cert-check on one too many random blog posts
out there, threw my toys out of the pram and ripped it out.

Use '--servercert XXXXX' instead. The first time you connect, it'll
*tell* you the value of XXXXX that you need to use to bypass the
prompt:

Certificate from VPN server "casper" failed verification.
Reason: certificate expired
To trust this server in future, perhaps add this to your command line:
    --servercert sha256:73fb5e9c7f07862d3210d55a9ffcb901e6fcab30e3e7d2117c4fc3de43a8716e
Enter 'yes' to accept, 'no' to abort; anything else to view: 

And actually you only need the first few digits of the hash. So even if
you're typing it manually, you ought to manage 'sha256:73fb'.


-- 
dwmw2
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5760 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/openconnect-devel/attachments/20161215/a119cb18/attachment.bin>

From dwmw2 at infradead.org  Thu Dec 15 00:59:52 2016
From: dwmw2 at infradead.org (David Woodhouse)
Date: Thu, 15 Dec 2016 08:59:52 +0000
Subject: [PATCH] add new_keys argument to esp_setup_keys() and comment
 clarifying esp.secrets format
In-Reply-To: <1476891551-14489-1-git-send-email-dlenski@gmail.com>
References: <1476891551-14489-1-git-send-email-dlenski@gmail.com>
Message-ID: <1481792392.98151.66.camel@infradead.org>

On Wed, 2016-10-19 at 08:39 -0700, Daniel Lenski wrote:
> -???????unsigned char secrets[0x40];
> +???????unsigned char secrets[0x40]; /* Encryption key bytes, then HMAC key bytes */

You're allowed to object to that horridness and split it into two
separate fields for the encryption and HMAC keys, instead of just
documenting it.

In fact, one might argue that would be the better approach...

> -???????vpninfo->old_esp_maxseq = vpninfo->esp_in[vpninfo->current_esp_in].seq + 32;
> -???????vpninfo->current_esp_in ^= 1;
> +???????if (new_keys) {
> +???????????????vpninfo->old_esp_maxseq = vpninfo->esp_in[vpninfo->current_esp_in].seq + 32;
> +???????????????vpninfo->current_esp_in ^= 1;
> +???????}

Hm, do you not want that part in setup_esp_keys()? That's where we flip
to the other incoming ESP setup,?while still allowing a few more
packets to be received on the existing one. Is there really no
rekeying?

Perhaps that part wants moving *out* of setup_esp_keys() to it callers?
And in fact perhaps you could do the new_keys bit that way too? Just
make an oncp_setup_esp_keys() function which creates the new keys and
*then* calls the generic setup_esp_keys()? Note that the flip to the
new incoming ESP setup has to be done *first*, or at least taken into
account.

-- 
dwmw2
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5760 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/openconnect-devel/attachments/20161215/86c1ffeb/attachment-0001.bin>

From gaute at div.org  Thu Dec 15 01:00:45 2016
From: gaute at div.org (Gaute Amundsen)
Date: Thu, 15 Dec 2016 10:00:45 +0100
Subject: Trouble with juniper connection - invalid HMAC
In-Reply-To: <e40948a1-545a-dcfb-4c8e-9aea1fa3b2b8@div.org>
References: <e40948a1-545a-dcfb-4c8e-9aea1fa3b2b8@div.org>
Message-ID: <dbbab2bb-ca35-63fe-70e5-c529ffa90465@div.org>

It seems 7.08 still has the same issue in my case.

Any suggestions?

G.


./configure --with-vpnc-script=/usr/share/vpnc-scripts/vpnc-script
BUILD OPTIONS:
   SSL library:            OpenSSL
   PKCS#11 support:        no
   DTLS support:           yes
   ESP support:            yes
   libproxy support:       no
   RSA SecurID support:    no
   PSKC OATH file support: no
   GSSAPI support:         no
   Yubikey support:        no
   LZ4 compression:        no
   Java bindings:          no
   Build docs:             no
   Unit tests:             no

make check
...
PASS: lzstest
PASS: seqtest
FAIL: bad_dtls_test
============================================================================
Testsuite summary for openconnect 7.08
============================================================================
# TOTAL: 3
# PASS:  2
# SKIP:  0
# XFAIL: 0
# FAIL:  1
# XPASS: 0
# ERROR: 0


With -vv

ping -c1 -W 2 -s 1394 host.tld - succeeds

Sent ESP packet of 116 bytes
No work to do; sleeping for 10000 ms...
Received ESP packet of 132 bytes
No work to do; sleeping for 15000 ms...
Sent ESP packet of 1444 bytes
Sent ESP packet of 84 bytes
No work to do; sleeping for 15000 ms...
Received ESP packet of 1460 bytes
No work to do; sleeping for 15000 ms...
Sent ESP packet of 116 bytes
No work to do; sleeping for 15000 ms...
Received ESP packet of 164 bytes
No work to do; sleeping for 15000 ms...


ping -c1 -W 2 -s 1395 host.tld - fails

Sent ESP packet of 116 bytes
No work to do; sleeping for 4000 ms...
Received ESP packet of 132 bytes
No work to do; sleeping for 15000 ms...
Sent ESP packet of 1444 bytes
Sent ESP packet of 100 bytes
No work to do; sleeping for 15000 ms...
Received ESP packet of 1460 bytes
Received ESP packet with invalid HMAC
No work to do; sleeping for 15000 ms...


ifconfig

tun0      Link encap:UNSPEC  HWaddr 
00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
           inet addr:10.150.4.56  P-t-P:10.150.4.56 Mask:255.255.255.255
           UP POINTOPOINT RUNNING NOARP MULTICAST  MTU:1400 Metric:1
           RX packets:120 errors:0 dropped:0 overruns:0 frame:0
           TX packets:135 errors:0 dropped:0 overruns:0 carrier:0
           collisions:0 txqueuelen:500
           RX bytes:23520 (23.5 KB)  TX bytes:22269 (22.2 KB)


I also have some Wireshark captures showing "malformed packet" when 
trying to open an RDP connection using Remmina.




From gaute at div.org  Thu Dec 15 02:11:57 2016
From: gaute at div.org (Gaute Amundsen)
Date: Thu, 15 Dec 2016 11:11:57 +0100
Subject: Trouble with juniper connection - invalid HMAC
In-Reply-To: <1481794241.98151.71.camel@infradead.org>
References: <e40948a1-545a-dcfb-4c8e-9aea1fa3b2b8@div.org>
 <dbbab2bb-ca35-63fe-70e5-c529ffa90465@div.org>
 <1481794241.98151.71.camel@infradead.org>
Message-ID: <413140ab-141f-b26a-c072-2f3992642b92@div.org>

No worries, thanks for quick response this time :)

Unfortunately it seems that made no difference.

I did:
make clean
git pull
git apply patch_MTU.txt
./autogen.sh
./configure --with-vpnc-script=/usr/share/vpnc-scripts/vpnc-script
make

Just to make sure:

$ ./openconnect -V
OpenConnect version v7.08-3-ga01a167-dirty
Using OpenSSL. Features present: TPM (OpenSSL ENGINE not present), HOTP 
software token, TOTP software token, DTLS

$ grep buf_append_tlv_be32 oncp.c
static void buf_append_tlv_be32(struct oc_text_buf *buf, uint16_t val, 
uint32_t data)
     buf_append_tlv_be32(reqbuf, 2, vpninfo->reqmtu);


1394 bytes

Sent ESP packet of 116 bytes
No work to do; sleeping for 10000 ms...
Received ESP packet of 132 bytes
No work to do; sleeping for 15000 ms...
Sent ESP packet of 1444 bytes
Sent ESP packet of 84 bytes
No work to do; sleeping for 15000 ms...
Received ESP packet of 1460 bytes
No work to do; sleeping for 15000 ms...
Sent ESP packet of 116 bytes
No work to do; sleeping for 15000 ms...
Received ESP packet of 164 bytes
No work to do; sleeping for 15000 ms...


1395 bytes

Sent ESP packet of 116 bytes
No work to do; sleeping for 11000 ms...
Received ESP packet of 132 bytes
No work to do; sleeping for 15000 ms...
Sent ESP packet of 1444 bytes
Sent ESP packet of 100 bytes
No work to do; sleeping for 15000 ms...
Received ESP packet of 1460 bytes
Received ESP packet with invalid HMAC
No work to do; sleeping for 15000 ms...


G.


On 15. des. 2016 10:30, David Woodhouse wrote:
> On Thu, 2016-12-15 at 10:00 +0100, Gaute Amundsen wrote:
>> It seems 7.08 still has the same issue in my case.
> Oops, apologies for missing that.
>
> This should probably fix the fact that --mtu doesn't work. Please
> confirm, and I'll fix it.
>
> diff --git a/oncp.c b/oncp.c
> index afcbe8b..249f8dc 100644
> --- a/oncp.c
> +++ b/oncp.c
> @@ -767,7 +767,7 @@ int oncp_connect(struct openconnect_info *vpninfo)
>   	kmp = reqbuf->pos;
>   	buf_append_tlv(reqbuf, 6, 0, NULL); /* TLV group 6 */
>   	group = reqbuf->pos;
> -	buf_append_tlv_be32(reqbuf, 2, vpninfo->ip_info.mtu);
> +	buf_append_tlv_be32(reqbuf, 2, vpninfo->reqmtu);
>   	if (buf_error(reqbuf)) {
>   		vpn_progress(vpninfo, PRG_ERR,
>   			     _("Error creating oNCP negotiation request\n"));
>
>
>> With -vv
>>
>> ping -c1 -W 2 -s 1394 host.tld - succeeds
>>
>> Sent ESP packet of 116 bytes
>> No work to do; sleeping for 10000 ms...
>> Received ESP packet of 132 bytes
>> No work to do; sleeping for 15000 ms...
>> Sent ESP packet of 1444 bytes
>> Sent ESP packet of 84 bytes
>> No work to do; sleeping for 15000 ms...
>> Received ESP packet of 1460 bytes
>> No work to do; sleeping for 15000 ms...
>> Sent ESP packet of 116 bytes
>> No work to do; sleeping for 15000 ms...
>> Received ESP packet of 164 bytes
>> No work to do; sleeping for 15000 ms...
>>
>>
>> ping -c1 -W 2 -s 1395 host.tld - fails
>>
>> Sent ESP packet of 116 bytes
>> No work to do; sleeping for 4000 ms...
>> Received ESP packet of 132 bytes
>> No work to do; sleeping for 15000 ms...
>> Sent ESP packet of 1444 bytes
>> Sent ESP packet of 100 bytes
>> No work to do; sleeping for 15000 ms...
>> Received ESP packet of 1460 bytes
>> Received ESP packet with invalid HMAC
>> No work to do; sleeping for 15000 ms...
> Hm, please could I have simultaneous captures of *both* the tun0 device
> traffic, *and* the UDP Internet traffic between your public-facing
> network adapter and the VPN server. Along with the verbose output of
> openconnect where it gives the ESP keys I'll need to decrypt the
> latter.
>
> Kill the session before you send the email (on general principles you
> don't want to be giving out the keys to a live session), and try not to
> have any other traffic on the VPN when you do it (partly for ease of
> analysis, and partly because you don't want to show me anything else).
>
> You can send that in private mail if you prefer. Thanks.
>



From dwmw2 at infradead.org  Thu Dec 15 02:16:36 2016
From: dwmw2 at infradead.org (David Woodhouse)
Date: Thu, 15 Dec 2016 10:16:36 +0000
Subject: Trouble with juniper connection - invalid HMAC
In-Reply-To: <413140ab-141f-b26a-c072-2f3992642b92@div.org>
References: <e40948a1-545a-dcfb-4c8e-9aea1fa3b2b8@div.org>
 <dbbab2bb-ca35-63fe-70e5-c529ffa90465@div.org>
 <1481794241.98151.71.camel@infradead.org>
 <413140ab-141f-b26a-c072-2f3992642b92@div.org>
Message-ID: <1481796996.98151.74.camel@infradead.org>

On Thu, 2016-12-15 at 11:11 +0100, Gaute Amundsen wrote:
> No worries, thanks for quick response this time :)
> 
> Unfortunately it seems that made no difference.

Hm.

diff --git a/oncp.c b/oncp.c
index afcbe8b..b8f6c50 100644
--- a/oncp.c
+++ b/oncp.c
@@ -181,6 +181,12 @@ static int process_attr(struct openconnect_info *vpninfo, int group, int attr,
 		vpn_progress(vpninfo, PRG_DEBUG,
 			     _("Received MTU %d from server\n"),
 			     vpninfo->ip_info.mtu);
+		if (vpninfo->reqmtu && vpninfo->ip_info.mtu > vpninfo->reqmtu) {
+			vpn_progress(vpninfo, PRG_ERR,
+				     "Limiting server MTU %d to %d\n",
+				     vpninfo->ip_info.mtu, vpninfo->reqmtu);
+			vpninfo->ip_info.mtu = vpninfo->reqmtu;
+		}
 		break;
 
 	case GRP_ATTR(2, 1):
@@ -767,7 +773,8 @@ int oncp_connect(struct openconnect_info *vpninfo)
 	kmp = reqbuf->pos;
 	buf_append_tlv(reqbuf, 6, 0, NULL); /* TLV group 6 */
 	group = reqbuf->pos;
-	buf_append_tlv_be32(reqbuf, 2, vpninfo->ip_info.mtu);
+	vpn_progress(vpninfo, PRG_ERR, "Requesting MTU %d\n", vpninfo->reqmtu);
+	buf_append_tlv_be32(reqbuf, 2, vpninfo->reqmtu);
 	if (buf_error(reqbuf)) {
 		vpn_progress(vpninfo, PRG_ERR,
 			     _("Error creating oNCP negotiation request\n"));
-- 
dwmw2
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5760 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/openconnect-devel/attachments/20161215/b4d18e48/attachment.bin>

From dwmw2 at infradead.org  Thu Dec 15 01:30:41 2016
From: dwmw2 at infradead.org (David Woodhouse)
Date: Thu, 15 Dec 2016 09:30:41 +0000
Subject: Trouble with juniper connection - invalid HMAC
In-Reply-To: <dbbab2bb-ca35-63fe-70e5-c529ffa90465@div.org>
References: <e40948a1-545a-dcfb-4c8e-9aea1fa3b2b8@div.org>
 <dbbab2bb-ca35-63fe-70e5-c529ffa90465@div.org>
Message-ID: <1481794241.98151.71.camel@infradead.org>

On Thu, 2016-12-15 at 10:00 +0100, Gaute Amundsen wrote:
> It seems 7.08 still has the same issue in my case.

Oops, apologies for missing that.

This should probably fix the fact that --mtu doesn't work. Please
confirm, and I'll fix it.

diff --git a/oncp.c b/oncp.c
index afcbe8b..249f8dc 100644
--- a/oncp.c
+++ b/oncp.c
@@ -767,7 +767,7 @@ int oncp_connect(struct openconnect_info *vpninfo)
 	kmp = reqbuf->pos;
 	buf_append_tlv(reqbuf, 6, 0, NULL); /* TLV group 6 */
 	group = reqbuf->pos;
-	buf_append_tlv_be32(reqbuf, 2, vpninfo->ip_info.mtu);
+	buf_append_tlv_be32(reqbuf, 2, vpninfo->reqmtu);
 	if (buf_error(reqbuf)) {
 		vpn_progress(vpninfo, PRG_ERR,
 			     _("Error creating oNCP negotiation request\n"));


> With -vv
> 
> ping -c1 -W 2 -s 1394 host.tld - succeeds
> 
> Sent ESP packet of 116 bytes
> No work to do; sleeping for 10000 ms...
> Received ESP packet of 132 bytes
> No work to do; sleeping for 15000 ms...
> Sent ESP packet of 1444 bytes
> Sent ESP packet of 84 bytes
> No work to do; sleeping for 15000 ms...
> Received ESP packet of 1460 bytes
> No work to do; sleeping for 15000 ms...
> Sent ESP packet of 116 bytes
> No work to do; sleeping for 15000 ms...
> Received ESP packet of 164 bytes
> No work to do; sleeping for 15000 ms...
> 
> 
> ping -c1 -W 2 -s 1395 host.tld - fails
> 
> Sent ESP packet of 116 bytes
> No work to do; sleeping for 4000 ms...
> Received ESP packet of 132 bytes
> No work to do; sleeping for 15000 ms...
> Sent ESP packet of 1444 bytes
> Sent ESP packet of 100 bytes
> No work to do; sleeping for 15000 ms...
> Received ESP packet of 1460 bytes
> Received ESP packet with invalid HMAC
> No work to do; sleeping for 15000 ms...

Hm, please could I have simultaneous captures of *both* the tun0 device
traffic, *and* the UDP Internet?traffic between your public-facing
network adapter and the VPN server. Along with the verbose output of
openconnect where it gives the ESP keys I'll need to decrypt the
latter.

Kill the session before you send the email (on general principles you
don't want to be giving out the keys to a live session), and try not to
have any other traffic on the VPN when you do it (partly for ease of
analysis, and partly because you don't want to show me anything else).

You can send that in private mail if you prefer. Thanks.

-- 
dwmw2
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5760 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/openconnect-devel/attachments/20161215/3f5124ca/attachment-0001.bin>

From thomas at glanzmann.de  Thu Dec 15 08:32:03 2016
From: thomas at glanzmann.de (Thomas Glanzmann)
Date: Thu, 15 Dec 2016 17:32:03 +0100
Subject: Use nginx ngx_stream_ssl_preread_module to connect to ocserv using
 proxy protocol v2
Message-ID: <20161215163203.GA23192@glanzmann.de>

Hello,
I would like to use nginx sni proxy feature to dispatch ssl traffic to
ocserv. My setup is as follows:

nginx:

stream {
        upstream webserver {
                server 127.0.0.1:443;
        }

        upstream ocserv {
                server 88.198.249.254:4443;
        }

        map $ssl_preread_server_name $name {
                vpn.gmvl.de ocserv;
                default webserver;
        }

        server {
                proxy_protocol on;
                listen 88.198.249.254:443;
                listen [2a01:4f8:b0:2fff::2]:443;

                proxy_pass  $name;
                ssl_preread on;
        }
}

ocserv:
auth = "pam[gid-min=1000]"
listen-host = 88.198.249.254
tcp-port = 4443
udp-port = 443
run-as-user = nobody
run-as-group = nogroup
socket-file = /var/run/ocserv-socket
server-cert = /etc/letsencrypt.sh/certs/vpn.gmvl.de/fullchain.pem
server-key = /etc/letsencrypt.sh/certs/vpn.gmvl.de/privkey.pem
dh-params = /etc/nginx/dhparam.pem
isolate-workers = true
max-clients = 16
max-same-clients = 0
listen-proxy-proto = true
rate-limit-ms = 100
keepalive = 32400
dpd = 90
mobile-dpd = 1800
try-mtu-discovery = false
cert-user-oid = 0.9.2342.19200300.100.1.1
tls-priorities = "NORMAL:%SERVER_PRECEDENCE:%COMPAT:-RSA:-VERS-SSL3.0:-ARCFOUR-128"
auth-timeout = 40
min-reauth-time = 120
max-ban-score = 50
ban-reset-time = 300
cookie-timeout = 300
deny-roaming = false
rekey-time = 172800
rekey-method = ssl
use-utmp = true
use-occtl = true
pid-file = /var/run/ocserv.pid
device = vpns
predictable-ips = true
default-domain = gmvl.de
ipv4-network = 10.12.12.0
ipv4-netmask = 255.255.255.0
ipv6-network = 2a01:4f8:bb:4fd::/64
ipv6-subnet-prefix = 128
dns = 10.10.10.1
dns = 2a01:4f8:b0:2fff::2
ping-leases = false
route = default
cisco-client-compat = true
dtls-legacy = true

When I try to connect using openconnect I can see in the nginx
sni_error.log:

2016/12/15 17:09:00 [error] 21043#0: *7426 recv() failed (104: Connection reset by peer) while proxying connection, client: 17.198.249.166, server: 88.198.249.254:443, upstream: "88.198.249.254:4443", bytes from/to client:0/0, bytes from/to upstream:0/316

And in syslog:

daemon:Dec 15 17:09:00 infra ocserv[21622]: worker:  worker-proxyproto.c:156: proxy-hdr: invalid v2 header
daemon:Dec 15 17:09:00 infra ocserv[21622]: worker:  worker-vpn.c:560: could not parse proxy protocol header; discarding connection
daemon:Dec 15 17:09:00 infra ocserv[18385]: main: 88.198.249.254:55976 user disconnected (reason: unspecified, rx: 0, tx: 0)

It seems that ocserv does not understand the proxy protocol header from
nginx? Has anyone else tried a similar setup? Otherwise I'll try to
debug the problem and make a patch ready.

Cheers,
        Thomas


From n.mavrogiannopoulos at gmail.com  Thu Dec 15 11:18:01 2016
From: n.mavrogiannopoulos at gmail.com (Nikos Mavrogiannopoulos)
Date: Thu, 15 Dec 2016 20:18:01 +0100
Subject: Use nginx ngx_stream_ssl_preread_module to connect to ocserv
 using proxy protocol v2
In-Reply-To: <20161215163203.GA23192@glanzmann.de>
References: <20161215163203.GA23192@glanzmann.de>
Message-ID: <CAJU7zaL1PuGxPTNjOuKM4_3pKKOzkzD5Uu3US4hzU9WW3GjNkQ@mail.gmail.com>

On Thu, Dec 15, 2016 at 5:32 PM, Thomas Glanzmann <thomas at glanzmann.de> wrote:
> Hello,
> I would like to use nginx sni proxy feature to dispatch ssl traffic to
> ocserv. My setup is as follows:
> daemon:Dec 15 17:09:00 infra ocserv[21622]: worker:  worker-proxyproto.c:156: proxy-hdr: invalid v2 header

Are you sure that the nginx module you are using supports the proxy
protocol version 2?

regards,
Nikos


From thomas at glanzmann.de  Thu Dec 15 13:36:37 2016
From: thomas at glanzmann.de (Thomas Glanzmann)
Date: Thu, 15 Dec 2016 22:36:37 +0100
Subject: Use nginx ngx_stream_ssl_preread_module to connect to ocserv
 using proxy protocol v2
In-Reply-To: <CAJU7zaL1PuGxPTNjOuKM4_3pKKOzkzD5Uu3US4hzU9WW3GjNkQ@mail.gmail.com>
References: <20161215163203.GA23192@glanzmann.de>
 <CAJU7zaL1PuGxPTNjOuKM4_3pKKOzkzD5Uu3US4hzU9WW3GjNkQ@mail.gmail.com>
Message-ID: <20161215213637.GC23728@glanzmann.de>

Hello Nikos,

> Are you sure that the nginx module you are using supports the proxy
> protocol version 2?

you're probably right. Nginx seems to support only version 1 of the
proxy protocol because I can't see the binary header preamble. Can
someone confirm?

https://thomas.glanzmann.de/tmp/nginx.pcap

Cheers,
        Thomas


From maxim at nginx.com  Fri Dec 16 00:13:15 2016
From: maxim at nginx.com (Maxim Konovalov)
Date: Fri, 16 Dec 2016 11:13:15 +0300
Subject: Use nginx ngx_stream_ssl_preread_module to connect to ocserv
 using proxy protocol v2
In-Reply-To: <20161215213637.GC23728@glanzmann.de>
References: <20161215163203.GA23192@glanzmann.de>
 <CAJU7zaL1PuGxPTNjOuKM4_3pKKOzkzD5Uu3US4hzU9WW3GjNkQ@mail.gmail.com>
 <20161215213637.GC23728@glanzmann.de>
Message-ID: <4fdf57e3-0475-49f4-3b0c-d9cea903efb9@nginx.com>

On 12/16/16 12:36 AM, Thomas Glanzmann wrote:
> Hello Nikos,
> 
>> Are you sure that the nginx module you are using supports the proxy
>> protocol version 2?
> 
> you're probably right. Nginx seems to support only version 1 of the
> proxy protocol because I can't see the binary header preamble. Can
> someone confirm?
> 
> https://thomas.glanzmann.de/tmp/nginx.pcap
> 
Yes, that's right -- no support for the proxy proto v2.

-- 
Maxim Konovalov


From nam.nguyen at smartmobilefactory.com  Mon Dec 19 03:51:49 2016
From: nam.nguyen at smartmobilefactory.com (Nam Nguyen)
Date: Mon, 19 Dec 2016 12:51:49 +0100
Subject: is observe "per app vpn" compatible ?
Message-ID: <2BEAE1ED-29CB-42D0-8D08-D0D0FEA353FD@smartmobilefactory.com>

regards,

-- 


Smart Mobile Factory GmbH, Franz?sische Str. 24, 10117 Berlin 
https://smartmobilefactory.com

Sitz: Berlin, Amtsgericht Charlottenburg, Handelsregister Berlin HRB 124077 
B, Gesch?ftsf?hrer: R?diger Wei?, Dr. Leif E. G?ritz

This e-mail may contain confidential and/or privileged information. If you 
are not the intended recipient (or have received this e-mail in error) 
please notify the sender immediately and destroy this e-mail. Any 
unauthorised copying, disclosure or distribution of the material in this 
e-mail is strictly forbidden.



From mtmiller at debian.org  Thu Dec 22 14:40:46 2016
From: mtmiller at debian.org (Mike Miller)
Date: Thu, 22 Dec 2016 14:40:46 -0800
Subject: [PATCH] tests: allow running tests with alternate ocserv
Message-ID: <20161222224046.vq7djzdyzsthmybh@galago.mtmxr.com>

Allow $OCSERV in the caller's environment to override the default ocserv
system installation.

Signed-off-by: Mike Miller <mtmiller at debian.org>
---
 tests/common.sh | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/tests/common.sh b/tests/common.sh
index 6d5736a..fbfde7a 100644
--- a/tests/common.sh
+++ b/tests/common.sh
@@ -19,13 +19,13 @@
 
 #this test can only be run as root
 
-if ! test -x /usr/sbin/ocserv;then
+OCSERV=${OCSERV:-/usr/sbin/ocserv}
+
+if ! test -x ${OCSERV};then
 	echo "You need ocserv to run this test"
 	exit 77
 fi
 
-OCSERV=/usr/sbin/ocserv
-
 SOCKDIR="./sockwrap.$$.tmp"
 mkdir -p $SOCKDIR
 export SOCKET_WRAPPER_DIR=$SOCKDIR
-- 
2.10.2


From robert.io at outlook.com  Fri Dec 23 00:44:00 2016
From: robert.io at outlook.com (Robert .)
Date: Fri, 23 Dec 2016 08:44:00 +0000
Subject: OpenConnect stops working after reboot on Ubuntu 16.04
Message-ID: <DB5PR10MB0022EA595960818428DD54F5E8950@DB5PR10MB0022.EURPRD10.PROD.OUTLOOK.COM>

Hi,

I have the problem described in the subject and i'm hoping its something silly i have / haven't done.

First i install OpenConnect using the following command:
?~$?sudo apt-get install openconnect

Then i connect using the following command:
 ~$ echo "password" | sudo openconnect --user=username --passwd-on-stdin anyconnect.example.com &

So far so good and it works as expected.  But when i reboot and try the first command again it just prints  "[1] {pid}" e.g "[1] 1234" at the terminal and after some time (sorry i have timed it) the following is printed to the terminal:
[1]+ Stopped                       echo "password" | sudo openconnect --user=username --passwd-on-stdin anyconnect.example.com

If i remove and install OpenConnect again it works until i reboot again.

So is this a bug or have i done something wrong?

thanks


From dwmw2 at infradead.org  Fri Dec 23 01:57:31 2016
From: dwmw2 at infradead.org (David Woodhouse)
Date: Fri, 23 Dec 2016 09:57:31 +0000
Subject: OpenConnect stops working after reboot on Ubuntu 16.04
In-Reply-To: <DB5PR10MB0022EA595960818428DD54F5E8950@DB5PR10MB0022.EURPRD10.PROD.OUTLOOK.COM>
References: <DB5PR10MB0022EA595960818428DD54F5E8950@DB5PR10MB0022.EURPRD10.PROD.OUTLOOK.COM>
Message-ID: <1482487051.4342.19.camel@infradead.org>

On Fri, 2016-12-23 at 08:44 +0000, Robert . wrote:
> 
> I have the problem described in the subject and i'm hoping its
> something silly i have / haven't done.
> 
> First i install OpenConnect using the following command:
> ?~$?sudo apt-get install openconnect
> 
> Then i connect using the following command:
> ?~$ echo "password" | sudo openconnect --user=username --passwd-on-
> stdin anyconnect.example.com &
> 
> So far so good and it works as expected.? But when i reboot and try
> the first command again it just prints? "[1] {pid}" e.g "[1] 1234" at
> the terminal and after some time (sorry i have timed it) the
> following is printed to the terminal:
> [1]+ Stopped?????????????????????? echo "password" | sudo openconnect
> --user=username --passwd-on-stdin anyconnect.example.com
> 
> If i remove and install OpenConnect again it works until i reboot
> again.

Sudo will only ask for a password the first time it's used (in a given
time period, on a given terminal).

So when you remove and install OpenConnect, I assume you use sudo. And
then when you *connect*, I'm guessing you did that from the same
terminal and it worked because you weren't asked for your password.

If you run it from another terminal, or after rebooting, then it
doesn't work because you've put the *whole* series of commands (sudo...
openconnect) into the background with that '&' at the end of your
command line. So sudo wants to prompt for a password, but it can't
because it's running in the background.

You don't want sudo itself to run in the background; you want it to
prompt for your password immediately, and then just run openconnect in
the background. So instead of
? sudo openconnect --passwd-on-stdin vpn.example.com <<< password &

You want the '-b' argument to sudo:
? sudo -b openconnect --passwd-on-stdin vpn.example.com <<< password?

Or better still, let OpenConnect actually *connect* in the foreground
too, then only background itself when you're authenticated correctly.
That way you see if anything goes wrong. That's the '-b' argument too,
but to openconnect instead of sudo:
?sudo openconnect -b --passwd-on-stdin <<< password

(Hm, I think we might have broken 'openconnect -b' in 7.08 with the MTU
detection. I'll have to take a closer look at that in the next few
days.)

But then again, why use the command line at all? NetworkManager has
support for openconnect. It's kind of broken in Ubuntu with?
https://bugs.launchpad.net/bugs/1609700?and (especcally in conjunction
with)?https://bugs.launchpad.net/bugs/1575354?but you can work around
and live with those (or just switch to a better-maintained distribution
where stuff is expected to work and bugs do get fixed).
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 4938 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/openconnect-devel/attachments/20161223/54c6324e/attachment.bin>

From robert.io at outlook.com  Fri Dec 23 04:53:18 2016
From: robert.io at outlook.com (Robert .)
Date: Fri, 23 Dec 2016 12:53:18 +0000
Subject: OpenConnect stops working after reboot on Ubuntu 16.04
In-Reply-To: <1482487051.4342.19.camel@infradead.org>
References: <DB5PR10MB0022EA595960818428DD54F5E8950@DB5PR10MB0022.EURPRD10.PROD.OUTLOOK.COM>,
 <1482487051.4342.19.camel@infradead.org>
Message-ID: <DB5PR10MB0022D151521EBB8F46C2ACEBE8950@DB5PR10MB0022.EURPRD10.PROD.OUTLOOK.COM>

Thanks that was a speedy response and it worked a tread.

I used "sudo openconnect -b --user=username --passwd-on-stdin anyconnect.example.com <<< password" and i still get the console output telling me if there is any trouble :)

As for using the Network Manager i'll have a look but my linux experience is a bit short but i can with a bit of google foo work my way around it.  The console method of connecting was the option i found when googling, it worked and wasn't too much trouble.  I had been using it on a Pi without issue but i had a better PC gathering dust and wanted to use that instead, thats when i encountered this problem. 

What i've been doing is connecting to my work VPN and NATing it by setting up ip_forward and running the following commands once i have connected to the VPN:
sudo iptables -t nat -A POSTROUTING -o tun0 -j MASQUERADE
sudo iptables -A FORWARD -i tun0 -o eth1 -m state --state RELATED,ESTABLISHED -j ACCEPT
sudo iptables -A FORWARD -i eth1 -o tun0 -j ACCEPT

And the routing any requests to their network via the PC.  This means i don't have to have a VPN client on each of my VM's and i can split internet traffic through my ISP and work traffic down the VPN :)

Once again thank you very much for you speedy response i wasn't expecting anything so soon, have a lovely xmas and a very happy new year.

From: David Woodhouse <dwmw2 at infradead.org>
Sent: 23 December 2016 09:57
To: Robert .; openconnect-devel at lists.infradead.org
Subject: Re: OpenConnect stops working after reboot on Ubuntu 16.04
?   
On Fri, 2016-12-23 at 08:44 +0000, Robert . wrote:
> 
> I have the problem described in the subject and i'm hoping its
> something silly i have / haven't done.
> 
> First i install OpenConnect using the following command:
> ?~$?sudo apt-get install openconnect
> 
> Then i connect using the following command:
> ?~$ echo "password" | sudo openconnect --user=username --passwd-on-
> stdin anyconnect.example.com &
> 
> So far so good and it works as expected.? But when i reboot and try
> the first command again it just prints? "[1] {pid}" e.g "[1] 1234" at
> the terminal and after some time (sorry i have timed it) the
> following is printed to the terminal:
> [1]+ Stopped?????????????????????? echo "password" | sudo openconnect
> --user=username --passwd-on-stdin anyconnect.example.com
> 
> If i remove and install OpenConnect again it works until i reboot
> again.

Sudo will only ask for a password the first time it's used (in a given
time period, on a given terminal).

So when you remove and install OpenConnect, I assume you use sudo. And
then when you *connect*, I'm guessing you did that from the same
terminal and it worked because you weren't asked for your password.

If you run it from another terminal, or after rebooting, then it
doesn't work because you've put the *whole* series of commands (sudo...
openconnect) into the background with that '&' at the end of your
command line. So sudo wants to prompt for a password, but it can't
because it's running in the background.

You don't want sudo itself to run in the background; you want it to
prompt for your password immediately, and then just run openconnect in
the background. So instead of
? sudo openconnect --passwd-on-stdin vpn.example.com <<< password &

You want the '-b' argument to sudo:
? sudo -b openconnect --passwd-on-stdin vpn.example.com <<< password?

Or better still, let OpenConnect actually *connect* in the foreground
too, then only background itself when you're authenticated correctly.
That way you see if anything goes wrong. That's the '-b' argument too,
but to openconnect instead of sudo:
?sudo openconnect -b --passwd-on-stdin <<< password

(Hm, I think we might have broken 'openconnect -b' in 7.08 with the MTU
detection. I'll have to take a closer look at that in the next few
days.)

But then again, why use the command line at all? NetworkManager has
support for openconnect. It's kind of broken in Ubuntu with?
https://bugs.launchpad.net/bugs/1609700?and (especcally in conjunction
with)?https://bugs.launchpad.net/bugs/1575354?but you can work around
and live with those (or just switch to a better-maintained distribution
where stuff is expected to work and bugs do get fixed).
    

From eduardo.gilmore at atlinas.com  Fri Dec 23 12:45:10 2016
From: eduardo.gilmore at atlinas.com (USPS Support)
Date: Fri, 23 Dec 2016 21:45:10 +0100
Subject: Parcel ID005411664 delivery problems, please review
Message-ID: <38f81d29779cceeb9614878f24117e8c@atlinas.com>

Dear Customer,

Your item has arrived at December 21, but our courier was not able to deliver the parcel.

Review the document that is attached to this e-mail!

Sincerely yours,
Eduardo Gilmore,
USPS Support Agent.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: Ground-Label-005411664.zip
Type: application/zip
Size: 5336 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/openconnect-devel/attachments/20161223/228125f2/attachment.zip>

From dlenski at gmail.com  Sat Dec 24 15:16:22 2016
From: dlenski at gmail.com (Daniel Lenski)
Date: Sat, 24 Dec 2016 15:16:22 -0800
Subject: [PATCH] add new_keys argument to esp_setup_keys() and comment
 clarifying esp.secrets format
In-Reply-To: <1481792392.98151.66.camel@infradead.org>
References: <1476891551-14489-1-git-send-email-dlenski@gmail.com>
 <1481792392.98151.66.camel@infradead.org>
Message-ID: <CAOw_LSGUNqyoiQ7x45JfUmqc+yibacJaondeS=Z2htscJnvxwQ@mail.gmail.com>

On Thu, Dec 15, 2016 at 12:59 AM, David Woodhouse <dwmw2 at infradead.org> wrote:
> On Wed, 2016-10-19 at 08:39 -0700, Daniel Lenski wrote:
>> -       unsigned char secrets[0x40];
>> +       unsigned char secrets[0x40]; /* Encryption key bytes, then HMAC key bytes */
>
> You're allowed to object to that horridness and split it into two
> separate fields for the encryption and HMAC keys, instead of just
> documenting it.

Okay. I don't know that much about security primitives, and thought
there might be some reason to avoid padding between the as-stored
encryption and HMAC keys. I was certainly wondering how it had been
done in the first place.

> In fact, one might argue that would be the better approach...

Yes, I assume OpenConnect jams them together like this only because
that's the form in which Juniper provides the keys.

>
>> -       vpninfo->old_esp_maxseq = vpninfo->esp_in[vpninfo->current_esp_in].seq + 32;
>> -       vpninfo->current_esp_in ^= 1;
>> +       if (new_keys) {
>> +               vpninfo->old_esp_maxseq = vpninfo->esp_in[vpninfo->current_esp_in].seq + 32;
>> +               vpninfo->current_esp_in ^= 1;
>> +       }
>
> Hm, do you not want that part in setup_esp_keys()? That's where we flip
> to the other incoming ESP setup, while still allowing a few more
> packets to be received on the existing one. Is there really no
> rekeying?

Right. setup_esp_keys() also generates new, random keys, however. And
with GP, the keys always come from the gateway in the big, verbose
getconfig XML file.

There is, as far as I can, never any requirement or signal from the
server to do a rekey. However, the client can effectively rekey by
closing the ESP connection, repulling the getconfig XML, and
restarting the ESP connection (that's what kill -USR2 / pause_cmd does
in my current implementation).

> Perhaps that part wants moving *out* of setup_esp_keys() to it callers?
> And in fact perhaps you could do the new_keys bit that way too? Just
> make an oncp_setup_esp_keys() function which creates the new keys and
> *then* calls the generic setup_esp_keys()? Note that the flip to the
> new incoming ESP setup has to be done *first*, or at least taken into
> account.

Yes, I think this would be the cleanest separation. Will do.

Thanks,
Dan


From dlenski at gmail.com  Sat Dec 24 15:19:00 2016
From: dlenski at gmail.com (Daniel Lenski)
Date: Sat, 24 Dec 2016 15:19:00 -0800
Subject: adding support for PAN Globalprotect (SSL+ESP) to Openconnect
In-Reply-To: <1481630390.98151.24.camel@infradead.org>
References: <CAOw_LSHF_CXMDAtKjN9P2x3_Y7+gHi4XdXeabbUbzDaBB9CUzg@mail.gmail.com>
 <1481630390.98151.24.camel@infradead.org>
Message-ID: <CAOw_LSEC6173Or5CcCMAA2gBQZMPug0FYvZuK2eZVdL=g1QEAw@mail.gmail.com>

(Sorry, I stopped watching this list for a bit)

On Tue, Dec 13, 2016 at 3:59 AM, David Woodhouse <dwmw2 at infradead.org> wrote:
>> I was planning to break down my changes into two parts to make them
>> easier to review. First, add *SSL-only* support for GP. This is a
>> pretty self-contained change, requiring only two small patches to the
>> rest of the OpenConnect code to work correctly:
>>
>> - Handle IPv4 route specified as either 10.1.2.0/255.255.255.0 or 10.1.2.0/24:
>>   http://lists.infradead.org/pipermail/openconnect-devel/2016-October/004039.html
>>
>> - Unset got_cancel_cmd after reacting to it, as is already done for
>> got_pause_cmd:
>>   http://lists.infradead.org/pipermail/openconnect-devel/2016-October/004038.html
>
> I've merged these and they'll be in the 7.08 release, which I'm working
> on right now and hoping to push out today unless anything explodes.

Great!

> I'm slightly reticent about merging new protocols but I think it makes
> sense, and your submissions so far have reassured me that you'll do a
> good job of maintaining it.
>
> However, I think I do need to lumber you with an additional hurdle
> before we merge your new protocol after 7.08 ? let's add a new API to
> check whether libopenconnect supports a given protocol, or to enumerate
> the protocols it supports. Currently it's just a hard-coded "if it's
> 7.05 or newer, it supports Juniper too", and I don't think we want that
> to continue. Let's do something explicit instead, and things like
> NetworkManager-openconnect can base their decisions on that.

For the protocol enumeration API, should the enumeration function
*just* return a linked list of protocol names
({"anyconnect","nc","gp"}) or will it need to return something more
complex with hints about possible authentication schemes, etc.? Since
all three of the current protocols use HTTPS for authentication and
HTTPS or <something UDP based> for the transport, I think a plain list
should suffice? but I'm not that familiar with the more exotic
authentication possibilities for Juniper and may be overlooking
something.

We had also discussed the possibility of "--protocol=autodetect" or
something to that effect. Is that still something you'd want to have
ready in order for a merge? I do not currently have access to any
Juniper VPN, so I might have trouble testing it thoroughly.

Thanks,
Dan


From mtmiller at debian.org  Sat Dec 24 16:03:14 2016
From: mtmiller at debian.org (Mike Miller)
Date: Sat, 24 Dec 2016 16:03:14 -0800
Subject: [vpnc-script] breakage with commit 6f87b0fe
Message-ID: <20161225000314.nebfhgllsv2gvqvh@galago.mtmxr.com>

Hi, I'm seeing breakage with vpnc-script as of 6f87b0fe (Add support for
systemd-resolved).

I think relying on the existence of /usr/bin/busctl is not really
sufficient to say that systemd-resolved is actually in use on the
system. Any systemd-based system has busctl, but is not necessarily
using systemd-resolved. I don't know what a sufficient condition would
be, maybe checking that nsswitch.conf is configured for nss-resolve?

  grep -q '^hosts:.*\bresolve\b' /etc/nsswitch.conf

Other ideas? Thanks,

-- 
mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/openconnect-devel/attachments/20161224/cb04a354/attachment.sig>

From mtmiller at debian.org  Sat Dec 24 18:31:33 2016
From: mtmiller at debian.org (Mike Miller)
Date: Sat, 24 Dec 2016 18:31:33 -0800
Subject: OpenConnect 7.08 fails to compile on GNU/Hurd
Message-ID: <20161225023133.fliaeimi3xjjzduf@galago.mtmxr.com>

Hi,

OpenConnect 7.08 fails to build on GNU/Hurd, because the IPV6_TCLASS
option is not declared by glibc on that platform. This was introduced in
commit 37316927 (Add --passtos option to copy TOS/TCLASS from VPN
packets).

I can work around this by simply defining around this option. Would the
following patch work to safely and silently disable this feature in this
case?

--- a/ssl.c
+++ b/ssl.c
@@ -914,7 +914,11 @@
 		struct sockaddr_in6 *sin = (void *)vpninfo->dtls_addr;
 		sin->sin6_port = htons(port);
 		vpninfo->dtls_tos_proto = IPPROTO_IPV6;
+#if defined(IPV6_TCLASS)
 		vpninfo->dtls_tos_optname = IPV6_TCLASS;
+#else
+		vpninfo->dtls_tos_optname = 0;
+#endif
 	} else {
 		vpn_progress(vpninfo, PRG_ERR,
 			     _("Unknown protocol family %d. Cannot create UDP server address\n"),
-- 
mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/openconnect-devel/attachments/20161224/079b5439/attachment.sig>

From admin_tm at yaraw.com  Sat Dec 24 23:38:13 2016
From: admin_tm at yaraw.com (Mihail)
Date: Sun, 25 Dec 2016 12:38:13 +0500
Subject: cancel the certificate
Message-ID: <1744710575.20161225123813@yaraw.com>


Hello!
Thank you for your program. I liked her very much. I use it to access the corporate network. Everything works fine. But faced with a problem. My connection is with a certificate. There are a few users. One of the employees dismissed from work.
  How to cancel the certificate of the officer that he could no longer connect?
Regards, Mikhail!

-- 
? ?????????,
 Mihail                          mailto:admin_tm at yaraw.com




From n.mavrogiannopoulos at gmail.com  Mon Dec 26 01:21:02 2016
From: n.mavrogiannopoulos at gmail.com (Nikos Mavrogiannopoulos)
Date: Mon, 26 Dec 2016 10:21:02 +0100
Subject: cancel the certificate
In-Reply-To: <1744710575.20161225123813@yaraw.com>
References: <1744710575.20161225123813@yaraw.com>
Message-ID: <CAJU7za+Z6sBsstk5ecEMGp+_3TFs8Rq1JiJMePCpZ+reT6+f7Q@mail.gmail.com>

If your question is for ocserv, I'd suggest to check the manual [0] on
revoking a client certificate.

regards,
Nikos

[0]. http://www.infradead.org/ocserv/manual.html#heading5


On Sun, Dec 25, 2016 at 8:38 AM, Mihail <admin_tm at yaraw.com> wrote:
>
> Hello!
> Thank you for your program. I liked her very much. I use it to access the corporate network. Everything works fine. But faced with a problem. My connection is with a certificate. There are a few users. One of the employees dismissed from work.
>   How to cancel the certificate of the officer that he could no longer connect?
> Regards, Mikhail!
>
> --
> ? ?????????,
>  Mihail                          mailto:admin_tm at yaraw.com
>
>
>
> _______________________________________________
> openconnect-devel mailing list
> openconnect-devel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/openconnect-devel


From tpadilha84 at gmail.com  Mon Dec 26 05:14:13 2016
From: tpadilha84 at gmail.com (Thiago Padilha)
Date: Mon, 26 Dec 2016 10:14:13 -0300
Subject: [vpnc-script] breakage with commit 6f87b0fe
In-Reply-To: <20161225000314.nebfhgllsv2gvqvh@galago.mtmxr.com>
References: <20161225000314.nebfhgllsv2gvqvh@galago.mtmxr.com>
Message-ID: <CAAq2XdqZDSpuhbCRPJo3F_hDExZpunduNRy3Z2OmLuufm+Cpww@mail.gmail.com>

It was naive to assume that the existence of /usr/bin/busctl means
systemd-resolved is being used. I don't know about /etc/nsswitch.conf, but the
following patch should fix it by adding a couple of additional checks.

Signed-off-by: Thiago de Arruda <tpadilha84 at gmail.com>
---
 vpnc-script | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-Re-vpnc-script-breakage-with-commit-6f87b0fe.patch
Type: text/x-patch
Size: 787 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/openconnect-devel/attachments/20161226/27c9135b/attachment.bin>

From n.mavrogiannopoulos at gmail.com  Mon Dec 26 08:39:23 2016
From: n.mavrogiannopoulos at gmail.com (Nikos Mavrogiannopoulos)
Date: Mon, 26 Dec 2016 17:39:23 +0100
Subject: [PATCH] improve xml config retrieval
Message-ID: <CAJU7zaKhRpqixFe3HGDKAyd60c--N2jUX2aJN7L9q0dgH-efCw@mail.gmail.com>

The attached patches improve the XML configuration handling. The first
fixes the behavior of the client not being able to download the
configuration if the server doesn't provide any hash (doesn't address
the case where openconnect_set_xmlsha1 isn't called). The second
documents the fact that the configuration can be downloaded -without
connecting- using the --authenticate and -x flags. The last is an RFC
to replace the callback APIs with something more reasonable, i.e., a
flag to ask the client to download the config and a function for the
caller to retrieve it.

I am not sure whether the SHA1 hash for xml configs is of any use at
all. Most likely the configuration will be downloaded, not every time,
but at specific times where the user would like to retrieve that
configuration (e.g., first connection, or first connection after a
client reset).

If we agree on the API for xml config retrieval, I'll continue with a
patch to parse these configuration files.

regards,
Nikos
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-fetch_config-download-config-if-no-SHA1-hash-of-prof.patch
Type: text/x-patch
Size: 2227 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/openconnect-devel/attachments/20161226/03f56d68/attachment-0003.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0002-man-page-improve-text-on-xmlconfig.patch
Type: text/x-patch
Size: 851 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/openconnect-devel/attachments/20161226/03f56d68/attachment-0004.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0003-RFC-Introduced-functions-to-request-the-retrieval-of.patch
Type: text/x-patch
Size: 7088 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/openconnect-devel/attachments/20161226/03f56d68/attachment-0005.bin>

From n.mavrogiannopoulos at gmail.com  Mon Dec 26 08:54:24 2016
From: n.mavrogiannopoulos at gmail.com (Nikos Mavrogiannopoulos)
Date: Mon, 26 Dec 2016 17:54:24 +0100
Subject: [PATCH] improve xml config retrieval
In-Reply-To: <CAJU7zaKhRpqixFe3HGDKAyd60c--N2jUX2aJN7L9q0dgH-efCw@mail.gmail.com>
References: <CAJU7zaKhRpqixFe3HGDKAyd60c--N2jUX2aJN7L9q0dgH-efCw@mail.gmail.com>
Message-ID: <CAJU7zaKoqnon1j064APKk5MRJf4iEikFmxgnuqq+FYjZ3_s13A@mail.gmail.com>

Updated versions of these patches will be placed at:
https://gitlab.com/nmav/openconnect/tree/xml-config-improve


On Mon, Dec 26, 2016 at 5:39 PM, Nikos Mavrogiannopoulos
<n.mavrogiannopoulos at gmail.com> wrote:
> The attached patches improve the XML configuration handling. The first
> fixes the behavior of the client not being able to download the
> configuration if the server doesn't provide any hash (doesn't address
> the case where openconnect_set_xmlsha1 isn't called). The second
> documents the fact that the configuration can be downloaded -without
> connecting- using the --authenticate and -x flags. The last is an RFC
> to replace the callback APIs with something more reasonable, i.e., a
> flag to ask the client to download the config and a function for the
> caller to retrieve it.
>
> I am not sure whether the SHA1 hash for xml configs is of any use at
> all. Most likely the configuration will be downloaded, not every time,
> but at specific times where the user would like to retrieve that
> configuration (e.g., first connection, or first connection after a
> client reset).
>
> If we agree on the API for xml config retrieval, I'll continue with a
> patch to parse these configuration files.
>
> regards,
> Nikos


From mtmiller at debian.org  Mon Dec 26 09:43:09 2016
From: mtmiller at debian.org (Mike Miller)
Date: Mon, 26 Dec 2016 09:43:09 -0800
Subject: [vpnc-script] breakage with commit 6f87b0fe
In-Reply-To: <CAAq2XdqZDSpuhbCRPJo3F_hDExZpunduNRy3Z2OmLuufm+Cpww@mail.gmail.com>
References: <20161225000314.nebfhgllsv2gvqvh@galago.mtmxr.com>
 <CAAq2XdqZDSpuhbCRPJo3F_hDExZpunduNRy3Z2OmLuufm+Cpww@mail.gmail.com>
Message-ID: <20161226174309.wp4nvud2vbglv7l6@galago.mtmxr.com>

On Mon, Dec 26, 2016 at 10:14:13 -0300, Thiago Padilha wrote:
> It was naive to assume that the existence of /usr/bin/busctl means
> systemd-resolved is being used. I don't know about /etc/nsswitch.conf, but the
> following patch should fix it by adding a couple of additional checks.

Ack, this works for me, thanks for the quick improvement.

As a nitpick, I think it's generally bad to rely on "/usr/bin/foo". How
about something like

  [ -n "$(busctl --version 2>/dev/null)" ]

instead?

-- 
mike


From dlenski at gmail.com  Mon Dec 26 15:53:44 2016
From: dlenski at gmail.com (Dan Lenski)
Date: Mon, 26 Dec 2016 15:53:44 -0800
Subject: [PATCH] enumerate supported VPN protocols via
 openconnect_get_supported_protocols()
In-Reply-To: <1481630390.98151.24.camel@infradead.org>
References: <1481630390.98151.24.camel@infradead.org>
Message-ID: <20161226235344.29128-1-dlenski@gmail.com>

Add a new public function, openconnect_get_supported_protocols(), which
returns a list of protocols supported by the client.  Each supported
protocol has a short name (as accepted by the --protocol command-line
option), description, and list of flags; currently, the only flags are:

  * OPENCONNECT_PROTO_TCP (TCP transport supported)
  * OPENCONNECT_PROTO_UDP (UDP transport supported)

Signed-off-by: Dan Lenski <dlenski at gmail.com>
---
 libopenconnect.map.in  |  5 +++++
 library.c              | 23 +++++++++++++++++++++++
 openconnect-internal.h |  1 +
 openconnect.h          | 14 ++++++++++++++
 4 files changed, 43 insertions(+)

diff --git a/libopenconnect.map.in b/libopenconnect.map.in
index 44eea34..7c3cc9e 100644
--- a/libopenconnect.map.in
+++ b/libopenconnect.map.in
@@ -92,6 +92,11 @@ OPENCONNECT_5_4 {
 	openconnect_set_pass_tos;
 } OPENCONNECT_5_3;
 
+OPENCONNECT_7_1 {
+ global:
+	openconnect_get_supported_protocols;
+} OPENCONNECT_5_4;
+
 OPENCONNECT_PRIVATE {
  global: @SYMVER_TIME@ @SYMVER_GETLINE@ @SYMVER_JAVA@ @SYMVER_ASPRINTF@ @SYMVER_VASPRINTF@ @SYMVER_WIN32_STRERROR@
 	openconnect_fopen_utf8;
diff --git a/library.c b/library.c
index 55a0dca..3ac0bf3 100644
--- a/library.c
+++ b/library.c
@@ -109,6 +109,7 @@ err:
 const struct vpn_proto openconnect_protos[] = {
 	{
 		.name = "anyconnect",
+		.description = "Cisco AnyConnect or ocserv",
 		.vpn_close_session = cstp_bye,
 		.tcp_connect = cstp_connect,
 		.tcp_mainloop = cstp_mainloop,
@@ -122,6 +123,7 @@ const struct vpn_proto openconnect_protos[] = {
 #endif
 	}, {
 		.name = "nc",
+		.description = "Juniper Network Connect (also supported by Junos Pulse servers)",
 		.vpn_close_session = NULL,
 		.tcp_connect = oncp_connect,
 		.tcp_mainloop = oncp_mainloop,
@@ -137,6 +139,7 @@ const struct vpn_proto openconnect_protos[] = {
 #endif
 	}, {
 		.name = "gp",
+		.description = "Palo Alto Networks' GlobalProtect",
 		.vpn_close_session = gpst_bye,
 		.tcp_connect = gpst_setup,
 		.tcp_mainloop = gpst_mainloop,
@@ -154,6 +157,26 @@ const struct vpn_proto openconnect_protos[] = {
 	{ /* NULL */ }
 };
 
+int openconnect_get_supported_protocols(struct oc_vpn_proto **protos)
+{
+	struct oc_vpn_proto *pr;
+	const struct vpn_proto *p;
+
+	*protos = pr = calloc(sizeof(openconnect_protos)/sizeof(*openconnect_protos), sizeof(*pr));
+	if (!pr)
+		return -ENOMEM;
+
+	for (p = openconnect_protos; p->name; p++, pr++) {
+		pr->name = p->name;
+		pr->description = p->description;
+		if (p->tcp_mainloop)
+			pr->flags |= OPENCONNECT_PROTO_TCP;
+		if (p->udp_mainloop)
+			pr->flags |= OPENCONNECT_PROTO_UDP;
+	}
+	return 0;
+}
+
 int openconnect_set_protocol(struct openconnect_info *vpninfo, const char *protocol)
 {
 	const struct vpn_proto *p;
diff --git a/openconnect-internal.h b/openconnect-internal.h
index 1ab73c5..466828d 100644
--- a/openconnect-internal.h
+++ b/openconnect-internal.h
@@ -257,6 +257,7 @@ struct http_auth_state {
 
 struct vpn_proto {
 	const char *name;
+	const char *description;
 	int (*vpn_close_session)(struct openconnect_info *vpninfo, const char *reason);
 
 	/* This does the full authentication, calling back as appropriate */
diff --git a/openconnect.h b/openconnect.h
index c621765..321a3cd 100644
--- a/openconnect.h
+++ b/openconnect.h
@@ -166,6 +166,19 @@ extern "C" {
 
 /****************************************************************************/
 
+/* Enumeration of supported VPN protocols */
+
+#define OPENCONNECT_PROTO_TCP 1
+#define OPENCONNECT_PROTO_UDP 2
+
+struct oc_vpn_proto {
+	const char *name;
+	const char *description;
+	unsigned int flags;
+};
+
+/****************************************************************************/
+
 /* Authentication form processing */
 
 #define OC_FORM_OPT_TEXT	1
@@ -640,6 +653,7 @@ int openconnect_has_oath_support(void);
 int openconnect_has_yubioath_support(void);
 int openconnect_has_system_key_support(void);
 
+int openconnect_get_supported_protocols(struct oc_vpn_proto **protos);
 int openconnect_set_protocol(struct openconnect_info *vpninfo, const char *protocol);
 
 struct addrinfo;
-- 
2.11.0



From dlenski at gmail.com  Mon Dec 26 16:31:51 2016
From: dlenski at gmail.com (Daniel Lenski)
Date: Mon, 26 Dec 2016 16:31:51 -0800
Subject: [PATCH] enumerate supported VPN protocols via
 openconnect_get_supported_protocols()
In-Reply-To: <20161226235344.29128-1-dlenski@gmail.com>
References: <1481630390.98151.24.camel@infradead.org>
 <20161226235344.29128-1-dlenski@gmail.com>
Message-ID: <CAOw_LSEZ9U533SaQ2ubK7fYH3fYOhL08388SpgvighDCsRbskg@mail.gmail.com>

On Mon, Dec 26, 2016 at 3:53 PM, Dan Lenski <dlenski at gmail.com> wrote:
> +OPENCONNECT_7_1 {
> + global:
> +       openconnect_get_supported_protocols;
> +} OPENCONNECT_5_4;
> +

Looks like I confused the API versions with the application versions.
I'll wait to see if anyone has any other comments on this patch before
re-submitting.

Thanks,
Dan


From tpadilha84 at gmail.com  Tue Dec 27 00:27:03 2016
From: tpadilha84 at gmail.com (Thiago Padilha)
Date: Tue, 27 Dec 2016 05:27:03 -0300
Subject: [vpnc-script] breakage with commit 6f87b0fe
In-Reply-To: <20161226174309.wp4nvud2vbglv7l6@galago.mtmxr.com>
References: <20161225000314.nebfhgllsv2gvqvh@galago.mtmxr.com>
 <CAAq2XdqZDSpuhbCRPJo3F_hDExZpunduNRy3Z2OmLuufm+Cpww@mail.gmail.com>
 <20161226174309.wp4nvud2vbglv7l6@galago.mtmxr.com>
Message-ID: <CAAq2Xdpt3S4=Z3sAUBiokbanm8r2R-L05tJ48BJgwL2P=rr+WA@mail.gmail.com>

Good call. More portable than the `which PROG 2>/dev/null` that I normally use.

Signed-off-by: Thiago de Arruda <tpadilha84 at gmail.com>
---
 vpnc-script | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-Re-vpnc-script-breakage-with-commit-6f87b0fe.patch
Type: text/x-patch
Size: 805 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/openconnect-devel/attachments/20161227/8481141d/attachment.bin>

From dlenski at gmail.com  Tue Dec 27 11:02:48 2016
From: dlenski at gmail.com (Daniel Lenski)
Date: Tue, 27 Dec 2016 11:02:48 -0800
Subject: [PATCH] refactor setup_esp_keys() to work for both Juniper and GP
In-Reply-To: <1481792392.98151.66.camel@infradead.org>
References: <1481792392.98151.66.camel@infradead.org>
Message-ID: <1482865368-24832-1-git-send-email-dlenski@gmail.com>

Added a new oncp_setup_esp_keys() which handles the generation of new, random
keys for Juniper, and then calls the generic setup_esp_keys(), which just
initializes the cipher and MAC.

Mostly reverts my previous take on this from 8796139f9.

This was suggested by David Woodhouse:

> Just make an oncp_setup_esp_keys() function which creates the new keys and
> *then* calls the generic setup_esp_keys()? Note that the flip to the
> new incoming ESP setup has to be done *first*, or at least taken into
> account.

Signed-off-by: Daniel Lenski <dlenski at gmail.com>
---
 gnutls-esp.c           | 18 +++---------------
 gpst.c                 |  5 +++--
 oncp.c                 | 31 +++++++++++++++++++++++++++++--
 openconnect-internal.h |  2 +-
 openssl-esp.c          | 18 +++---------------
 5 files changed, 39 insertions(+), 35 deletions(-)

diff --git a/gnutls-esp.c b/gnutls-esp.c
index 0b63e0f..7666f10 100644
--- a/gnutls-esp.c
+++ b/gnutls-esp.c
@@ -72,7 +72,7 @@ static int init_esp_ciphers(struct openconnect_info *vpninfo, struct esp *esp,
 	return 0;
 }
 
-int setup_esp_keys(struct openconnect_info *vpninfo, int new_keys)
+int setup_esp_keys(struct openconnect_info *vpninfo)
 {
 	struct esp *esp_in;
 	gnutls_mac_algorithm_t macalg;
@@ -106,23 +106,11 @@ int setup_esp_keys(struct openconnect_info *vpninfo, int new_keys)
 		return -EINVAL;
 	}
 
-	if (new_keys) {
-		vpninfo->old_esp_maxseq = vpninfo->esp_in[vpninfo->current_esp_in].seq + 32;
-		vpninfo->current_esp_in ^= 1;
-	}
+	vpninfo->old_esp_maxseq = vpninfo->esp_in[vpninfo->current_esp_in].seq + 32;
+	vpninfo->current_esp_in ^= 1;
 
 	esp_in = &vpninfo->esp_in[vpninfo->current_esp_in];
 
-	if (new_keys) {
-		if ((ret = gnutls_rnd(GNUTLS_RND_NONCE, &esp_in->spi, sizeof(esp_in->spi))) ||
-		    (ret = gnutls_rnd(GNUTLS_RND_RANDOM, &esp_in->secrets, sizeof(esp_in->secrets)))) {
-			vpn_progress(vpninfo, PRG_ERR,
-				     _("Failed to generate random keys for ESP: %s\n"),
-				     gnutls_strerror(ret));
-			return -EIO;
-		}
-	}
-
 	ret = init_esp_ciphers(vpninfo, &vpninfo->esp_out, macalg, encalg);
 	if (ret)
 		return ret;
diff --git a/gpst.c b/gpst.c
index 7179ecb..3346194 100644
--- a/gpst.c
+++ b/gpst.c
@@ -286,7 +286,8 @@ static int gpst_parse_config_xml(struct openconnect_info *vpninfo, xmlNode *xml_
 			}
 		} else if (xmlnode_is_named(xml_node, "ipsec")) {
 #ifdef HAVE_ESP
-			int c = (vpninfo->current_esp_in ^= 1);
+			/* setup_esp_keys() will swap the active incoming key-set */
+			int c = (vpninfo->current_esp_in ^ 1);
 			int enclen=0, maclen=0;
 			for (member = xml_node->children; member; member=member->next) {
 				s = NULL;
@@ -303,7 +304,7 @@ static int gpst_parse_config_xml(struct openconnect_info *vpninfo, xmlNode *xml_
 				free((void *)s);
 			}
 			if (vpninfo->dtls_state != DTLS_DISABLED) {
-				if (setup_esp_keys(vpninfo, 0))
+				if (setup_esp_keys(vpninfo))
 					vpn_progress(vpninfo, PRG_ERR, "Failed to setup ESP keys.\n");
 				else
 					vpninfo->dtls_times.last_rekey = time(NULL);
diff --git a/oncp.c b/oncp.c
index 61ff9cf..f58c389 100644
--- a/oncp.c
+++ b/oncp.c
@@ -523,6 +523,33 @@ static int parse_conf_pkt(struct openconnect_info *vpninfo, unsigned char *bytes
 	return 0;
 }
 
+static int oncp_setup_esp_keys(struct openconnect_info *vpninfo)
+{
+	int ret;
+	/* setup_esp_keys() will swap the active incoming key-set */
+	struct esp *esp_in = &vpninfo->esp_in[vpninfo->current_esp_in ^ 1];
+
+#if defined(OPENCONNECT_GNUTLS)
+	if ((ret = gnutls_rnd(GNUTLS_RND_NONCE, &esp_in->spi, sizeof(esp_in->spi))) ||
+	    (ret = gnutls_rnd(GNUTLS_RND_RANDOM, &esp_in->secrets, sizeof(esp_in->secrets)))) {
+		vpn_progress(vpninfo, PRG_ERR,
+			     _("Failed to generate random keys for ESP: %s\n"),
+			     gnutls_strerror(ret));
+		return -EIO;
+	}
+#elif defined(OPENCONNECT_OPENSSL)
+	if (!RAND_bytes((void *)&esp_in->spi, sizeof(esp_in->spi)) ||
+	    !RAND_bytes((void *)&esp_in->secrets, sizeof(esp_in->secrets))) {
+		vpn_progress(vpninfo, PRG_ERR,
+			     _("Failed to generate random keys for ESP:\n"));
+		openconnect_report_ssl_errors(vpninfo);
+		return -EIO;
+	}
+#endif
+
+	return setup_esp_keys(vpninfo);
+}
+
 int oncp_connect(struct openconnect_info *vpninfo)
 {
 	int ret, len, kmp, kmplen, group;
@@ -762,7 +789,7 @@ int oncp_connect(struct openconnect_info *vpninfo)
 	put_len16(reqbuf, kmp);
 
 #ifdef HAVE_ESP
-	if (!setup_esp_keys(vpninfo, 1)) {
+	if (!oncp_setup_esp_keys(vpninfo)) {
 		struct esp *esp = &vpninfo->esp_in[vpninfo->current_esp_in];
 		/* Since we'll want to do this in the oncp_mainloop too, where it's easier
 		 * *not* to have an oc_text_buf and build it up manually, and since it's
@@ -814,7 +841,7 @@ static int oncp_receive_espkeys(struct openconnect_info *vpninfo, int len)
 	int ret;
 
 	ret = parse_conf_pkt(vpninfo, vpninfo->cstp_pkt->oncp.kmp, len + 20, 301);
-	if (!ret && !setup_esp_keys(vpninfo, 1)) {
+	if (!ret && !oncp_setup_esp_keys(vpninfo)) {
 		struct esp *esp = &vpninfo->esp_in[vpninfo->current_esp_in];
 		unsigned char *p = vpninfo->cstp_pkt->oncp.kmp;
 
diff --git a/openconnect-internal.h b/openconnect-internal.h
index 466828d..c9f7b08 100644
--- a/openconnect-internal.h
+++ b/openconnect-internal.h
@@ -922,7 +922,7 @@ int esp_catch_probe(struct openconnect_info *vpninfo, struct pkt *pkt);
 int esp_catch_probe_gp(struct openconnect_info *vpninfo, struct pkt *pkt);
 
 /* {gnutls,openssl}-esp.c */
-int setup_esp_keys(struct openconnect_info *vpninfo, int new_keys);
+int setup_esp_keys(struct openconnect_info *vpninfo);
 void destroy_esp_ciphers(struct esp *esp);
 int decrypt_esp_packet(struct openconnect_info *vpninfo, struct esp *esp, struct pkt *pkt);
 int encrypt_esp_packet(struct openconnect_info *vpninfo, struct pkt *pkt);
diff --git a/openssl-esp.c b/openssl-esp.c
index f58d32f..9224388 100644
--- a/openssl-esp.c
+++ b/openssl-esp.c
@@ -112,7 +112,7 @@ static int init_esp_ciphers(struct openconnect_info *vpninfo, struct esp *esp,
 	return 0;
 }
 
-int setup_esp_keys(struct openconnect_info *vpninfo, int new_keys)
+int setup_esp_keys(struct openconnect_info *vpninfo)
 {
 	struct esp *esp_in;
 	const EVP_CIPHER *encalg;
@@ -146,23 +146,11 @@ int setup_esp_keys(struct openconnect_info *vpninfo, int new_keys)
 		return -EINVAL;
 	}
 
-	if (new_keys) {
-		vpninfo->old_esp_maxseq = vpninfo->esp_in[vpninfo->current_esp_in].seq + 32;
-		vpninfo->current_esp_in ^= 1;
-	}
+	vpninfo->old_esp_maxseq = vpninfo->esp_in[vpninfo->current_esp_in].seq + 32;
+	vpninfo->current_esp_in ^= 1;
 
 	esp_in = &vpninfo->esp_in[vpninfo->current_esp_in];
 
-	if (new_keys) {
-		if (!RAND_bytes((void *)&esp_in->spi, sizeof(esp_in->spi)) ||
-		    !RAND_bytes((void *)&esp_in->secrets, sizeof(esp_in->secrets))) {
-			vpn_progress(vpninfo, PRG_ERR,
-				     _("Failed to generate random keys for ESP:\n"));
-			openconnect_report_ssl_errors(vpninfo);
-			return -EIO;
-		}
-	}
-
 	ret = init_esp_ciphers(vpninfo, &vpninfo->esp_out, macalg, encalg, 0);
 	if (ret)
 		return ret;
-- 
2.7.4



From dlenski at gmail.com  Wed Dec 28 09:38:50 2016
From: dlenski at gmail.com (Daniel Lenski)
Date: Wed, 28 Dec 2016 09:38:50 -0800
Subject: [PATCH] store length of ESP encryption and HMAC keys so that they can
 be manipulated separately for both Juniper and GP
In-Reply-To: <1481792392.98151.66.camel@infradead.org>
References: <1481792392.98151.66.camel@infradead.org>
Message-ID: <1482946730-7519-1-git-send-email-dlenski@gmail.com>

David Woodhouse wrote:
> Daniel Lenski wrote:
>> -       unsigned char secrets[0x40];
>> +       unsigned char secrets[0x40]; /* Encryption key bytes, then HMAC key bytes */
>
> You're allowed to object to that horridness and split it into two
> separate fields for the encryption and HMAC keys, instead of just
> documenting it.
>
> In fact, one might argue that would be the better approach...

Signed-off-by: Daniel Lenski <dlenski at gmail.com>
---
 esp.c                  | 13 ++++---------
 gnutls-esp.c           |  4 ++--
 gpst.c                 | 28 +++++++++++++---------------
 oncp.c                 | 42 ++++++++++++++++++++++++++++++------------
 openconnect-internal.h |  5 ++++-
 openssl-esp.c          |  2 +-
 6 files changed, 54 insertions(+), 40 deletions(-)

diff --git a/esp.c b/esp.c
index f6b8f27..186858a 100644
--- a/esp.c
+++ b/esp.c
@@ -34,16 +34,13 @@ int print_esp_keys(struct openconnect_info *vpninfo, const char *name, struct es
 	int i;
 	const char *enctype, *mactype;
 	char enckey[256], mackey[256];
-	int enclen, maclen;
 
 	switch(vpninfo->esp_enc) {
 	case ENC_AES_128_CBC:
 		enctype = "AES-128-CBC (RFC3602)";
-		enclen = 16;
 		break;
 	case ENC_AES_256_CBC:
 		enctype = "AES-256-CBC (RFC3602)";
-		enclen = 32;
 		break;
 	default:
 		return -EINVAL;
@@ -51,20 +48,18 @@ int print_esp_keys(struct openconnect_info *vpninfo, const char *name, struct es
 	switch(vpninfo->esp_hmac) {
 	case HMAC_MD5:
 		mactype = "HMAC-MD5-96 (RFC2403)";
-		maclen = 16;
 		break;
 	case HMAC_SHA1:
 		mactype = "HMAC-SHA-1-96 (RFC2404)";
-		maclen = 20;
 		break;
 	default:
 		return -EINVAL;
 	}
 
-	for (i = 0; i < enclen; i++)
-		sprintf(enckey + (2 * i), "%02x", esp->secrets[i]);
-	for (i = 0; i < maclen; i++)
-		sprintf(mackey + (2 * i), "%02x", esp->secrets[enclen + i]);
+	for (i = 0; i < vpninfo->enc_key_len; i++)
+		sprintf(enckey + (2 * i), "%02x", esp->enc_key[i]);
+	for (i = 0; i < vpninfo->hmac_key_len; i++)
+		sprintf(mackey + (2 * i), "%02x", esp->hmac_key[i]);
 
 	vpn_progress(vpninfo, PRG_TRACE,
 		     _("Parameters for %s ESP: SPI 0x%08x\n"),
diff --git a/gnutls-esp.c b/gnutls-esp.c
index 14ea1da..f3ec72c 100644
--- a/gnutls-esp.c
+++ b/gnutls-esp.c
@@ -48,7 +48,7 @@ static int init_esp_ciphers(struct openconnect_info *vpninfo, struct esp *esp,
 	destroy_esp_ciphers(esp);
 
 	enc_key.size = gnutls_cipher_get_key_size(encalg);
-	enc_key.data = esp->secrets;
+	enc_key.data = esp->enc_key;
 
 	err = gnutls_cipher_init(&esp->cipher, encalg, &enc_key, NULL);
 	if (err) {
@@ -59,7 +59,7 @@ static int init_esp_ciphers(struct openconnect_info *vpninfo, struct esp *esp,
 	}
 
 	err = gnutls_hmac_init(&esp->hmac, macalg,
-			       esp->secrets + enc_key.size,
+			       esp->hmac_key,
 			       gnutls_hmac_get_len(macalg));
 	if (err) {
 		vpn_progress(vpninfo, PRG_ERR,
diff --git a/gpst.c b/gpst.c
index 3346194..f89e3d3 100644
--- a/gpst.c
+++ b/gpst.c
@@ -211,18 +211,18 @@ static int calculate_mtu(struct openconnect_info *vpninfo)
 static int set_esp_algo(struct openconnect_info *vpninfo, const char *s, int hmac)
 {
 	if (hmac) {
-		if (!strcmp(s, "sha1"))		{ vpninfo->esp_hmac = HMAC_SHA1; return 20; }
-		if (!strcmp(s, "md5"))		{ vpninfo->esp_hmac = HMAC_MD5; return 16; }
+		if (!strcmp(s, "sha1"))		{ vpninfo->esp_hmac = HMAC_SHA1; vpninfo->hmac_key_len = 20; return 0; }
+		if (!strcmp(s, "md5"))		{ vpninfo->esp_hmac = HMAC_MD5;  vpninfo->hmac_key_len = 16; return 0; }
 	} else {
 		if (!strcmp(s, "aes128") || !strcmp(s, "aes-128-cbc"))
-		                                { vpninfo->esp_enc = ENC_AES_128_CBC; return 16; }
-		if (!strcmp(s, "aes-256-cbc"))	{ vpninfo->esp_enc = ENC_AES_256_CBC; return 32; }
+		                                { vpninfo->esp_enc = ENC_AES_128_CBC; vpninfo->enc_key_len = 16; return 0; }
+		if (!strcmp(s, "aes-256-cbc"))	{ vpninfo->esp_enc = ENC_AES_256_CBC; vpninfo->enc_key_len = 32; return 0; }
 	}
 	vpn_progress(vpninfo, PRG_ERR, _("Unknown ESP %s algorithm: %s"), hmac ? "MAC" : "encryption", s);
 	return -ENOENT;
 }
 
-static int get_key_bits(xmlNode *xml_node, unsigned char *dest, int keybytes)
+static int get_key_bits(xmlNode *xml_node, unsigned char *dest)
 {
 	int bits = -1;
 	xmlNode *child;
@@ -233,12 +233,12 @@ static int get_key_bits(xmlNode *xml_node, unsigned char *dest, int keybytes)
 			bits = atoi(s);
 			free((void *)s);
 		} else if (xmlnode_get_text(child, "val", &s) == 0) {
-			for (p=s; *p && *(p+1) && p<s+(keybytes<<1); p+=2)
+			for (p=s; *p && *(p+1) && (bits-=8)>=0; p+=2)
 				*dest++ = unhex(p);
 			free((void *)s);
 		}
 	}
-	return (bits == (keybytes<<3)) ? 0 : -EINVAL;
+	return (bits == 0) ? 0 : -EINVAL;
 }
 
 /* Return value:
@@ -288,19 +288,17 @@ static int gpst_parse_config_xml(struct openconnect_info *vpninfo, xmlNode *xml_
 #ifdef HAVE_ESP
 			/* setup_esp_keys() will swap the active incoming key-set */
 			int c = (vpninfo->current_esp_in ^ 1);
-			int enclen=0, maclen=0;
 			for (member = xml_node->children; member; member=member->next) {
 				s = NULL;
 				if (!xmlnode_get_text(member, "udp-port", &s))		udp_sockaddr(vpninfo, atoi(s));
-				else if (!xmlnode_get_text(member, "enc-algo", &s)) 	enclen = set_esp_algo(vpninfo, s, 0);
-				else if (!xmlnode_get_text(member, "hmac-algo", &s))	maclen = set_esp_algo(vpninfo, s, 1);
+				else if (!xmlnode_get_text(member, "enc-algo", &s)) 	set_esp_algo(vpninfo, s, 0);
+				else if (!xmlnode_get_text(member, "hmac-algo", &s))	set_esp_algo(vpninfo, s, 1);
 				else if (!xmlnode_get_text(member, "c2s-spi", &s))	vpninfo->esp_out.spi = htonl(strtoul(s, NULL, 16));
 				else if (!xmlnode_get_text(member, "s2c-spi", &s))	vpninfo->esp_in[c].spi = htonl(strtoul(s, NULL, 16));
-				/* FIXME: this won't work if ekey or akey tags appears before algo tags */
-				else if (xmlnode_is_named(member, "ekey-c2s"))		get_key_bits(member, vpninfo->esp_out.secrets, enclen);
-				else if (xmlnode_is_named(member, "ekey-s2c"))		get_key_bits(member, vpninfo->esp_in[c].secrets, enclen);
-				else if (xmlnode_is_named(member, "akey-c2s"))		get_key_bits(member, vpninfo->esp_out.secrets+enclen, maclen);
-				else if (xmlnode_is_named(member, "akey-s2c"))		get_key_bits(member, vpninfo->esp_in[c].secrets+enclen, maclen);
+				else if (xmlnode_is_named(member, "ekey-c2s"))		get_key_bits(member, vpninfo->esp_out.enc_key);
+				else if (xmlnode_is_named(member, "ekey-s2c"))		get_key_bits(member, vpninfo->esp_in[c].enc_key);
+				else if (xmlnode_is_named(member, "akey-c2s"))		get_key_bits(member, vpninfo->esp_out.hmac_key);
+				else if (xmlnode_is_named(member, "akey-s2c"))		get_key_bits(member, vpninfo->esp_in[c].hmac_key);
 				free((void *)s);
 			}
 			if (vpninfo->dtls_state != DTLS_DISABLED) {
diff --git a/oncp.c b/oncp.c
index e6ff6c3..f5bcc75 100644
--- a/oncp.c
+++ b/oncp.c
@@ -286,11 +286,13 @@ static int process_attr(struct openconnect_info *vpninfo, int group, int attr,
 
 		if (attrlen != 1)
 			goto badlen;
-		if (data[0] == ENC_AES_128_CBC)
+		if (data[0] == ENC_AES_128_CBC) {
 			enctype = "AES-128";
-		else if (data[0] == ENC_AES_256_CBC)
+			vpninfo->enc_key_len = 16;
+		} else if (data[0] == ENC_AES_256_CBC) {
 			enctype = "AES-256";
-		else
+			vpninfo->enc_key_len = 32;
+		} else
 			enctype = "unknown";
 		vpn_progress(vpninfo, PRG_DEBUG, _("ESP encryption: 0x%02x (%s)\n"),
 			      data[0], enctype);
@@ -303,11 +305,13 @@ static int process_attr(struct openconnect_info *vpninfo, int group, int attr,
 
 		if (attrlen != 1)
 			goto badlen;
-		if (data[0] == HMAC_MD5)
+		if (data[0] == HMAC_MD5) {
 			mactype = "MD5";
-		else if (data[0] == HMAC_SHA1)
+			vpninfo->hmac_key_len = 16;
+		} else if (data[0] == HMAC_SHA1) {
 			mactype = "SHA1";
-		else
+			vpninfo->hmac_key_len = 20;
+		} else
 			mactype = "unknown";
 		vpn_progress(vpninfo, PRG_DEBUG, _("ESP HMAC: 0x%02x (%s)\n"),
 			      data[0], mactype);
@@ -373,7 +377,8 @@ static int process_attr(struct openconnect_info *vpninfo, int group, int attr,
 	case GRP_ATTR(7, 2):
 		if (attrlen != 0x40)
 			goto badlen;
-		memcpy(vpninfo->esp_out.secrets, data, 0x40);
+		/* data contains enc_key and hmac_key concatenated */
+		memcpy(vpninfo->esp_out.enc_key, data, 0x40);
 		vpn_progress(vpninfo, PRG_DEBUG, _("%d bytes of ESP secrets\n"),
 			     attrlen);
 		break;
@@ -474,6 +479,7 @@ static int parse_conf_pkt(struct openconnect_info *vpninfo, unsigned char *bytes
 {
 	int kmplen, kmpend, grouplen, groupend, group, attr, attrlen;
 	int ofs = 0;
+	int split_enc_hmac_keys = 0;
 
 	kmplen = load_be16(bytes + ofs + 18);
 	kmpend = ofs + kmplen;
@@ -517,9 +523,17 @@ static int parse_conf_pkt(struct openconnect_info *vpninfo, unsigned char *bytes
 				goto eparse;
 			if (process_attr(vpninfo, group, attr, bytes + ofs, attrlen))
 				goto eparse;
+			if (GRP_ATTR(group, attr)==GRP_ATTR(7, 2))
+				split_enc_hmac_keys = 1;
 			ofs += attrlen;
 		}
 	}
+
+	/* The encryption and HMAC keys are sent concatenated together in a block of 0x40 bytes;
+	   we can't split them apart until we know how long the encryption key is. */
+	if (split_enc_hmac_keys)
+		memcpy(vpninfo->esp_out.hmac_key, vpninfo->esp_out.enc_key + vpninfo->enc_key_len, vpninfo->hmac_key_len);
+
 	return 0;
 }
 
@@ -531,7 +545,8 @@ static int oncp_setup_esp_keys(struct openconnect_info *vpninfo)
 
 #if defined(OPENCONNECT_GNUTLS)
 	if ((ret = gnutls_rnd(GNUTLS_RND_NONCE, &esp_in->spi, sizeof(esp_in->spi))) ||
-	    (ret = gnutls_rnd(GNUTLS_RND_RANDOM, &esp_in->secrets, sizeof(esp_in->secrets)))) {
+	    (ret = gnutls_rnd(GNUTLS_RND_RANDOM, &esp_in->enc_key, vpninfo->enc_key_len)) ||
+	    (ret = gnutls_rnd(GNUTLS_RND_RANDOM, &esp_in->hmac_key, vpninfo->hmac_key_len)) ) {
 		vpn_progress(vpninfo, PRG_ERR,
 			     _("Failed to generate random keys for ESP: %s\n"),
 			     gnutls_strerror(ret));
@@ -539,7 +554,8 @@ static int oncp_setup_esp_keys(struct openconnect_info *vpninfo)
 	}
 #elif defined(OPENCONNECT_OPENSSL)
 	if (!RAND_bytes((void *)&esp_in->spi, sizeof(esp_in->spi)) ||
-	    !RAND_bytes((void *)&esp_in->secrets, sizeof(esp_in->secrets))) {
+	    !RAND_bytes((void *)&esp_in->enc_key, vpninfo->enc_key_len)) ||
+	    !RAND_bytes((void *)&esp_in->hmac_key, vpninfo->hmac_key_len)) ) {
 		vpn_progress(vpninfo, PRG_ERR,
 			     _("Failed to generate random keys for ESP:\n"));
 		openconnect_report_ssl_errors(vpninfo);
@@ -797,7 +813,8 @@ int oncp_connect(struct openconnect_info *vpninfo)
 		buf_append_bytes(reqbuf, esp_kmp_hdr, sizeof(esp_kmp_hdr));
 		buf_append_bytes(reqbuf, &esp->spi, sizeof(esp->spi));
 		buf_append_bytes(reqbuf, esp_kmp_part2, sizeof(esp_kmp_part2));
-		buf_append_bytes(reqbuf, &esp->secrets, sizeof(esp->secrets));
+		buf_append_bytes(reqbuf, &esp->enc_key, vpninfo->enc_key_len);
+		buf_append_bytes(reqbuf, &esp->hmac_key, 0x40 - vpninfo->enc_key_len);
 		if (buf_error(reqbuf)) {
 			vpn_progress(vpninfo, PRG_ERR,
 				     _("Error negotiating ESP keys\n"));
@@ -851,8 +868,9 @@ static int oncp_receive_espkeys(struct openconnect_info *vpninfo, int len)
 		p += sizeof(esp->spi);
 		memcpy(p, esp_kmp_part2, sizeof(esp_kmp_part2));
 		p += sizeof(esp_kmp_part2);
-		memcpy(p, esp->secrets, sizeof(esp->secrets));
-		p += sizeof(esp->secrets);
+		memcpy(p, esp->enc_key, vpninfo->enc_key_len);
+		memcpy(p+vpninfo->enc_key_len, esp->hmac_key, 0x40 - vpninfo->enc_key_len);
+		p += 0x40;
 		vpninfo->cstp_pkt->len = p - vpninfo->cstp_pkt->data;
 		store_le16(vpninfo->cstp_pkt->oncp.rec,
 			   (p - vpninfo->cstp_pkt->oncp.kmp));
diff --git a/openconnect-internal.h b/openconnect-internal.h
index c9f7b08..8deccca 100644
--- a/openconnect-internal.h
+++ b/openconnect-internal.h
@@ -348,7 +348,8 @@ struct esp {
 	uint64_t seq_backlog;
 	uint64_t seq;
 	uint32_t spi; /* Stored network-endian */
-	unsigned char secrets[0x40]; /* Encryption key bytes, then HMAC key bytes */
+	unsigned char enc_key[0x40]; /* Encryption key */
+	unsigned char hmac_key[0x40]; /* HMAC key */
 };
 
 struct openconnect_info {
@@ -372,6 +373,8 @@ struct openconnect_info {
 	int old_esp_maxseq;
 	struct esp esp_in[2];
 	struct esp esp_out;
+	int enc_key_len;
+	int hmac_key_len;
 
 	int tncc_fd; /* For Juniper TNCC */
 	const char *csd_xmltag;
diff --git a/openssl-esp.c b/openssl-esp.c
index 106a1f9..12dd761 100644
--- a/openssl-esp.c
+++ b/openssl-esp.c
@@ -99,7 +99,7 @@ static int init_esp_ciphers(struct openconnect_info *vpninfo, struct esp *esp,
 		destroy_esp_ciphers(esp);
 		return -ENOMEM;
 	}
-	if (!HMAC_Init_ex(esp->hmac, esp->secrets + EVP_CIPHER_key_length(encalg),
+	if (!HMAC_Init_ex(esp->hmac, esp->hmac_key,
 			  EVP_MD_size(macalg), macalg, NULL)) {
 		vpn_progress(vpninfo, PRG_ERR,
 			     _("Failed to initialize ESP HMAC\n"));
-- 
2.7.4



From dlenski at gmail.com  Wed Dec 28 09:44:38 2016
From: dlenski at gmail.com (Daniel Lenski)
Date: Wed, 28 Dec 2016 09:44:38 -0800
Subject: [PATCH] store length of ESP encryption and HMAC keys so that they
 can be manipulated separately for both Juniper and GP
In-Reply-To: <1482946730-7519-1-git-send-email-dlenski@gmail.com>
References: <1481792392.98151.66.camel@infradead.org>
 <1482946730-7519-1-git-send-email-dlenski@gmail.com>
Message-ID: <CAOw_LSGTYRBDkFYfTgykMUsSKnCcCOXvZzohLHE+hdpRVne2dg@mail.gmail.com>

This patch is a bit? redundant. The mapping between encryption
algorithms and encryption key length is not only stored in the vpninfo
structure, but it's also re-computed in several different places.

I would like to use the gnutls/openssl functions to determine key
length everywhere, but this would mean (a) storing backend-specific
algorithm identifiers and (b) adding a lot more #ifdef GNUTLS/OPENSSL.
Any thoughts?

Dan

On Wed, Dec 28, 2016 at 9:38 AM, Daniel Lenski <dlenski at gmail.com> wrote:
> David Woodhouse wrote:
>> Daniel Lenski wrote:
>>> -       unsigned char secrets[0x40];
>>> +       unsigned char secrets[0x40]; /* Encryption key bytes, then HMAC key bytes */
>>
>> You're allowed to object to that horridness and split it into two
>> separate fields for the encryption and HMAC keys, instead of just
>> documenting it.
>>
>> In fact, one might argue that would be the better approach...
>
> Signed-off-by: Daniel Lenski <dlenski at gmail.com>
> ---
>  esp.c                  | 13 ++++---------
>  gnutls-esp.c           |  4 ++--
>  gpst.c                 | 28 +++++++++++++---------------
>  oncp.c                 | 42 ++++++++++++++++++++++++++++++------------
>  openconnect-internal.h |  5 ++++-
>  openssl-esp.c          |  2 +-
>  6 files changed, 54 insertions(+), 40 deletions(-)
>
> diff --git a/esp.c b/esp.c
> index f6b8f27..186858a 100644
> --- a/esp.c
> +++ b/esp.c
> @@ -34,16 +34,13 @@ int print_esp_keys(struct openconnect_info *vpninfo, const char *name, struct es
>         int i;
>         const char *enctype, *mactype;
>         char enckey[256], mackey[256];
> -       int enclen, maclen;
>
>         switch(vpninfo->esp_enc) {
>         case ENC_AES_128_CBC:
>                 enctype = "AES-128-CBC (RFC3602)";
> -               enclen = 16;
>                 break;
>         case ENC_AES_256_CBC:
>                 enctype = "AES-256-CBC (RFC3602)";
> -               enclen = 32;
>                 break;
>         default:
>                 return -EINVAL;
> @@ -51,20 +48,18 @@ int print_esp_keys(struct openconnect_info *vpninfo, const char *name, struct es
>         switch(vpninfo->esp_hmac) {
>         case HMAC_MD5:
>                 mactype = "HMAC-MD5-96 (RFC2403)";
> -               maclen = 16;
>                 break;
>         case HMAC_SHA1:
>                 mactype = "HMAC-SHA-1-96 (RFC2404)";
> -               maclen = 20;
>                 break;
>         default:
>                 return -EINVAL;
>         }
>
> -       for (i = 0; i < enclen; i++)
> -               sprintf(enckey + (2 * i), "%02x", esp->secrets[i]);
> -       for (i = 0; i < maclen; i++)
> -               sprintf(mackey + (2 * i), "%02x", esp->secrets[enclen + i]);
> +       for (i = 0; i < vpninfo->enc_key_len; i++)
> +               sprintf(enckey + (2 * i), "%02x", esp->enc_key[i]);
> +       for (i = 0; i < vpninfo->hmac_key_len; i++)
> +               sprintf(mackey + (2 * i), "%02x", esp->hmac_key[i]);
>
>         vpn_progress(vpninfo, PRG_TRACE,
>                      _("Parameters for %s ESP: SPI 0x%08x\n"),
> diff --git a/gnutls-esp.c b/gnutls-esp.c
> index 14ea1da..f3ec72c 100644
> --- a/gnutls-esp.c
> +++ b/gnutls-esp.c
> @@ -48,7 +48,7 @@ static int init_esp_ciphers(struct openconnect_info *vpninfo, struct esp *esp,
>         destroy_esp_ciphers(esp);
>
>         enc_key.size = gnutls_cipher_get_key_size(encalg);
> -       enc_key.data = esp->secrets;
> +       enc_key.data = esp->enc_key;
>
>         err = gnutls_cipher_init(&esp->cipher, encalg, &enc_key, NULL);
>         if (err) {
> @@ -59,7 +59,7 @@ static int init_esp_ciphers(struct openconnect_info *vpninfo, struct esp *esp,
>         }
>
>         err = gnutls_hmac_init(&esp->hmac, macalg,
> -                              esp->secrets + enc_key.size,
> +                              esp->hmac_key,
>                                gnutls_hmac_get_len(macalg));
>         if (err) {
>                 vpn_progress(vpninfo, PRG_ERR,
> diff --git a/gpst.c b/gpst.c
> index 3346194..f89e3d3 100644
> --- a/gpst.c
> +++ b/gpst.c
> @@ -211,18 +211,18 @@ static int calculate_mtu(struct openconnect_info *vpninfo)
>  static int set_esp_algo(struct openconnect_info *vpninfo, const char *s, int hmac)
>  {
>         if (hmac) {
> -               if (!strcmp(s, "sha1"))         { vpninfo->esp_hmac = HMAC_SHA1; return 20; }
> -               if (!strcmp(s, "md5"))          { vpninfo->esp_hmac = HMAC_MD5; return 16; }
> +               if (!strcmp(s, "sha1"))         { vpninfo->esp_hmac = HMAC_SHA1; vpninfo->hmac_key_len = 20; return 0; }
> +               if (!strcmp(s, "md5"))          { vpninfo->esp_hmac = HMAC_MD5;  vpninfo->hmac_key_len = 16; return 0; }
>         } else {
>                 if (!strcmp(s, "aes128") || !strcmp(s, "aes-128-cbc"))
> -                                               { vpninfo->esp_enc = ENC_AES_128_CBC; return 16; }
> -               if (!strcmp(s, "aes-256-cbc"))  { vpninfo->esp_enc = ENC_AES_256_CBC; return 32; }
> +                                               { vpninfo->esp_enc = ENC_AES_128_CBC; vpninfo->enc_key_len = 16; return 0; }
> +               if (!strcmp(s, "aes-256-cbc"))  { vpninfo->esp_enc = ENC_AES_256_CBC; vpninfo->enc_key_len = 32; return 0; }
>         }
>         vpn_progress(vpninfo, PRG_ERR, _("Unknown ESP %s algorithm: %s"), hmac ? "MAC" : "encryption", s);
>         return -ENOENT;
>  }
>
> -static int get_key_bits(xmlNode *xml_node, unsigned char *dest, int keybytes)
> +static int get_key_bits(xmlNode *xml_node, unsigned char *dest)
>  {
>         int bits = -1;
>         xmlNode *child;
> @@ -233,12 +233,12 @@ static int get_key_bits(xmlNode *xml_node, unsigned char *dest, int keybytes)
>                         bits = atoi(s);
>                         free((void *)s);
>                 } else if (xmlnode_get_text(child, "val", &s) == 0) {
> -                       for (p=s; *p && *(p+1) && p<s+(keybytes<<1); p+=2)
> +                       for (p=s; *p && *(p+1) && (bits-=8)>=0; p+=2)
>                                 *dest++ = unhex(p);
>                         free((void *)s);
>                 }
>         }
> -       return (bits == (keybytes<<3)) ? 0 : -EINVAL;
> +       return (bits == 0) ? 0 : -EINVAL;
>  }
>
>  /* Return value:
> @@ -288,19 +288,17 @@ static int gpst_parse_config_xml(struct openconnect_info *vpninfo, xmlNode *xml_
>  #ifdef HAVE_ESP
>                         /* setup_esp_keys() will swap the active incoming key-set */
>                         int c = (vpninfo->current_esp_in ^ 1);
> -                       int enclen=0, maclen=0;
>                         for (member = xml_node->children; member; member=member->next) {
>                                 s = NULL;
>                                 if (!xmlnode_get_text(member, "udp-port", &s))          udp_sockaddr(vpninfo, atoi(s));
> -                               else if (!xmlnode_get_text(member, "enc-algo", &s))     enclen = set_esp_algo(vpninfo, s, 0);
> -                               else if (!xmlnode_get_text(member, "hmac-algo", &s))    maclen = set_esp_algo(vpninfo, s, 1);
> +                               else if (!xmlnode_get_text(member, "enc-algo", &s))     set_esp_algo(vpninfo, s, 0);
> +                               else if (!xmlnode_get_text(member, "hmac-algo", &s))    set_esp_algo(vpninfo, s, 1);
>                                 else if (!xmlnode_get_text(member, "c2s-spi", &s))      vpninfo->esp_out.spi = htonl(strtoul(s, NULL, 16));
>                                 else if (!xmlnode_get_text(member, "s2c-spi", &s))      vpninfo->esp_in[c].spi = htonl(strtoul(s, NULL, 16));
> -                               /* FIXME: this won't work if ekey or akey tags appears before algo tags */
> -                               else if (xmlnode_is_named(member, "ekey-c2s"))          get_key_bits(member, vpninfo->esp_out.secrets, enclen);
> -                               else if (xmlnode_is_named(member, "ekey-s2c"))          get_key_bits(member, vpninfo->esp_in[c].secrets, enclen);
> -                               else if (xmlnode_is_named(member, "akey-c2s"))          get_key_bits(member, vpninfo->esp_out.secrets+enclen, maclen);
> -                               else if (xmlnode_is_named(member, "akey-s2c"))          get_key_bits(member, vpninfo->esp_in[c].secrets+enclen, maclen);
> +                               else if (xmlnode_is_named(member, "ekey-c2s"))          get_key_bits(member, vpninfo->esp_out.enc_key);
> +                               else if (xmlnode_is_named(member, "ekey-s2c"))          get_key_bits(member, vpninfo->esp_in[c].enc_key);
> +                               else if (xmlnode_is_named(member, "akey-c2s"))          get_key_bits(member, vpninfo->esp_out.hmac_key);
> +                               else if (xmlnode_is_named(member, "akey-s2c"))          get_key_bits(member, vpninfo->esp_in[c].hmac_key);
>                                 free((void *)s);
>                         }
>                         if (vpninfo->dtls_state != DTLS_DISABLED) {
> diff --git a/oncp.c b/oncp.c
> index e6ff6c3..f5bcc75 100644
> --- a/oncp.c
> +++ b/oncp.c
> @@ -286,11 +286,13 @@ static int process_attr(struct openconnect_info *vpninfo, int group, int attr,
>
>                 if (attrlen != 1)
>                         goto badlen;
> -               if (data[0] == ENC_AES_128_CBC)
> +               if (data[0] == ENC_AES_128_CBC) {
>                         enctype = "AES-128";
> -               else if (data[0] == ENC_AES_256_CBC)
> +                       vpninfo->enc_key_len = 16;
> +               } else if (data[0] == ENC_AES_256_CBC) {
>                         enctype = "AES-256";
> -               else
> +                       vpninfo->enc_key_len = 32;
> +               } else
>                         enctype = "unknown";
>                 vpn_progress(vpninfo, PRG_DEBUG, _("ESP encryption: 0x%02x (%s)\n"),
>                               data[0], enctype);
> @@ -303,11 +305,13 @@ static int process_attr(struct openconnect_info *vpninfo, int group, int attr,
>
>                 if (attrlen != 1)
>                         goto badlen;
> -               if (data[0] == HMAC_MD5)
> +               if (data[0] == HMAC_MD5) {
>                         mactype = "MD5";
> -               else if (data[0] == HMAC_SHA1)
> +                       vpninfo->hmac_key_len = 16;
> +               } else if (data[0] == HMAC_SHA1) {
>                         mactype = "SHA1";
> -               else
> +                       vpninfo->hmac_key_len = 20;
> +               } else
>                         mactype = "unknown";
>                 vpn_progress(vpninfo, PRG_DEBUG, _("ESP HMAC: 0x%02x (%s)\n"),
>                               data[0], mactype);
> @@ -373,7 +377,8 @@ static int process_attr(struct openconnect_info *vpninfo, int group, int attr,
>         case GRP_ATTR(7, 2):
>                 if (attrlen != 0x40)
>                         goto badlen;
> -               memcpy(vpninfo->esp_out.secrets, data, 0x40);
> +               /* data contains enc_key and hmac_key concatenated */
> +               memcpy(vpninfo->esp_out.enc_key, data, 0x40);
>                 vpn_progress(vpninfo, PRG_DEBUG, _("%d bytes of ESP secrets\n"),
>                              attrlen);
>                 break;
> @@ -474,6 +479,7 @@ static int parse_conf_pkt(struct openconnect_info *vpninfo, unsigned char *bytes
>  {
>         int kmplen, kmpend, grouplen, groupend, group, attr, attrlen;
>         int ofs = 0;
> +       int split_enc_hmac_keys = 0;
>
>         kmplen = load_be16(bytes + ofs + 18);
>         kmpend = ofs + kmplen;
> @@ -517,9 +523,17 @@ static int parse_conf_pkt(struct openconnect_info *vpninfo, unsigned char *bytes
>                                 goto eparse;
>                         if (process_attr(vpninfo, group, attr, bytes + ofs, attrlen))
>                                 goto eparse;
> +                       if (GRP_ATTR(group, attr)==GRP_ATTR(7, 2))
> +                               split_enc_hmac_keys = 1;
>                         ofs += attrlen;
>                 }
>         }
> +
> +       /* The encryption and HMAC keys are sent concatenated together in a block of 0x40 bytes;
> +          we can't split them apart until we know how long the encryption key is. */
> +       if (split_enc_hmac_keys)
> +               memcpy(vpninfo->esp_out.hmac_key, vpninfo->esp_out.enc_key + vpninfo->enc_key_len, vpninfo->hmac_key_len);
> +
>         return 0;
>  }
>
> @@ -531,7 +545,8 @@ static int oncp_setup_esp_keys(struct openconnect_info *vpninfo)
>
>  #if defined(OPENCONNECT_GNUTLS)
>         if ((ret = gnutls_rnd(GNUTLS_RND_NONCE, &esp_in->spi, sizeof(esp_in->spi))) ||
> -           (ret = gnutls_rnd(GNUTLS_RND_RANDOM, &esp_in->secrets, sizeof(esp_in->secrets)))) {
> +           (ret = gnutls_rnd(GNUTLS_RND_RANDOM, &esp_in->enc_key, vpninfo->enc_key_len)) ||
> +           (ret = gnutls_rnd(GNUTLS_RND_RANDOM, &esp_in->hmac_key, vpninfo->hmac_key_len)) ) {
>                 vpn_progress(vpninfo, PRG_ERR,
>                              _("Failed to generate random keys for ESP: %s\n"),
>                              gnutls_strerror(ret));
> @@ -539,7 +554,8 @@ static int oncp_setup_esp_keys(struct openconnect_info *vpninfo)
>         }
>  #elif defined(OPENCONNECT_OPENSSL)
>         if (!RAND_bytes((void *)&esp_in->spi, sizeof(esp_in->spi)) ||
> -           !RAND_bytes((void *)&esp_in->secrets, sizeof(esp_in->secrets))) {
> +           !RAND_bytes((void *)&esp_in->enc_key, vpninfo->enc_key_len)) ||
> +           !RAND_bytes((void *)&esp_in->hmac_key, vpninfo->hmac_key_len)) ) {
>                 vpn_progress(vpninfo, PRG_ERR,
>                              _("Failed to generate random keys for ESP:\n"));
>                 openconnect_report_ssl_errors(vpninfo);
> @@ -797,7 +813,8 @@ int oncp_connect(struct openconnect_info *vpninfo)
>                 buf_append_bytes(reqbuf, esp_kmp_hdr, sizeof(esp_kmp_hdr));
>                 buf_append_bytes(reqbuf, &esp->spi, sizeof(esp->spi));
>                 buf_append_bytes(reqbuf, esp_kmp_part2, sizeof(esp_kmp_part2));
> -               buf_append_bytes(reqbuf, &esp->secrets, sizeof(esp->secrets));
> +               buf_append_bytes(reqbuf, &esp->enc_key, vpninfo->enc_key_len);
> +               buf_append_bytes(reqbuf, &esp->hmac_key, 0x40 - vpninfo->enc_key_len);
>                 if (buf_error(reqbuf)) {
>                         vpn_progress(vpninfo, PRG_ERR,
>                                      _("Error negotiating ESP keys\n"));
> @@ -851,8 +868,9 @@ static int oncp_receive_espkeys(struct openconnect_info *vpninfo, int len)
>                 p += sizeof(esp->spi);
>                 memcpy(p, esp_kmp_part2, sizeof(esp_kmp_part2));
>                 p += sizeof(esp_kmp_part2);
> -               memcpy(p, esp->secrets, sizeof(esp->secrets));
> -               p += sizeof(esp->secrets);
> +               memcpy(p, esp->enc_key, vpninfo->enc_key_len);
> +               memcpy(p+vpninfo->enc_key_len, esp->hmac_key, 0x40 - vpninfo->enc_key_len);
> +               p += 0x40;
>                 vpninfo->cstp_pkt->len = p - vpninfo->cstp_pkt->data;
>                 store_le16(vpninfo->cstp_pkt->oncp.rec,
>                            (p - vpninfo->cstp_pkt->oncp.kmp));
> diff --git a/openconnect-internal.h b/openconnect-internal.h
> index c9f7b08..8deccca 100644
> --- a/openconnect-internal.h
> +++ b/openconnect-internal.h
> @@ -348,7 +348,8 @@ struct esp {
>         uint64_t seq_backlog;
>         uint64_t seq;
>         uint32_t spi; /* Stored network-endian */
> -       unsigned char secrets[0x40]; /* Encryption key bytes, then HMAC key bytes */
> +       unsigned char enc_key[0x40]; /* Encryption key */
> +       unsigned char hmac_key[0x40]; /* HMAC key */
>  };
>
>  struct openconnect_info {
> @@ -372,6 +373,8 @@ struct openconnect_info {
>         int old_esp_maxseq;
>         struct esp esp_in[2];
>         struct esp esp_out;
> +       int enc_key_len;
> +       int hmac_key_len;
>
>         int tncc_fd; /* For Juniper TNCC */
>         const char *csd_xmltag;
> diff --git a/openssl-esp.c b/openssl-esp.c
> index 106a1f9..12dd761 100644
> --- a/openssl-esp.c
> +++ b/openssl-esp.c
> @@ -99,7 +99,7 @@ static int init_esp_ciphers(struct openconnect_info *vpninfo, struct esp *esp,
>                 destroy_esp_ciphers(esp);
>                 return -ENOMEM;
>         }
> -       if (!HMAC_Init_ex(esp->hmac, esp->secrets + EVP_CIPHER_key_length(encalg),
> +       if (!HMAC_Init_ex(esp->hmac, esp->hmac_key,
>                           EVP_MD_size(macalg), macalg, NULL)) {
>                 vpn_progress(vpninfo, PRG_ERR,
>                              _("Failed to initialize ESP HMAC\n"));
> --
> 2.7.4
>


From mtmiller at debian.org  Fri Dec 30 13:28:26 2016
From: mtmiller at debian.org (Mike Miller)
Date: Fri, 30 Dec 2016 13:28:26 -0800
Subject: [vpnc-script] breakage with commit 6f87b0fe
In-Reply-To: <CAAq2Xdpt3S4=Z3sAUBiokbanm8r2R-L05tJ48BJgwL2P=rr+WA@mail.gmail.com>
References: <20161225000314.nebfhgllsv2gvqvh@galago.mtmxr.com>
 <CAAq2XdqZDSpuhbCRPJo3F_hDExZpunduNRy3Z2OmLuufm+Cpww@mail.gmail.com>
 <20161226174309.wp4nvud2vbglv7l6@galago.mtmxr.com>
 <CAAq2Xdpt3S4=Z3sAUBiokbanm8r2R-L05tJ48BJgwL2P=rr+WA@mail.gmail.com>
Message-ID: <20161230212826.r3v5yvdrxfowmsmm@galago.mtmxr.com>

On Tue, Dec 27, 2016 at 05:27:03 -0300, Thiago Padilha wrote:
> Good call. More portable than the `which PROG 2>/dev/null` that I normally use.

Thanks, this looks perfect and works for me.

-- 
mike


