Send connman mailing list submissions to
[email protected]
To subscribe or unsubscribe via email, send a message with subject or
body 'help' to
[email protected]
You can reach the person managing the list at
[email protected]
When replying, please edit your Subject line so it is more specific
than "Re: Contents of connman digest..."
Today's Topics:
1. Re: [PATCH 6/7] doc: Add new OpenConnect PKCS#12 parameters to VPN agent
API
(Jussi Laakkonen)
----------------------------------------------------------------------
Date: Thu, 3 Oct 2019 12:43:26 +0300
From: Jussi Laakkonen <[email protected]>
Subject: Re: [PATCH 6/7] doc: Add new OpenConnect PKCS#12 parameters
to VPN agent API
To: David Woodhouse <[email protected]>, [email protected]
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8; format=flowed
Hi David,
Thanks for the comment and for the document, good read. I understand
that all of the different PKCS formats should be supported. I'll try to
make them work as well with v2 of these patches. There is a solid reason
why I used only PKCS#12 in this first version of rewrite: it is the one
that is always protected with a pass phrase. The approach is to query
the pass phrase using VPN agent at startup, as mandatory option. PKCS#8
seems to have it as an option.
The approach I selected is because I do have some issues with
OpenConnect (tried with versions 8.02 and 8.05) when the given PKCS pass
phrase (at startup using --passwd-on-stdin) is invalid. OpenConnect is
set to log only to syslog (--syslog), and non-interactive (--non-inter)
is used so OC should not ask for anything. But still in the case with
invalid PKCS pass phrase a deadlock happens as OC awaits for user input.
In main.c of OpenConnect it seems that non-interactive mode is working
nicely. But when pass phrase is to be requested using
ssl.c:request_passphrase() -> library.c:process_auth_form() there is no
way for the library to check if non-interactive mode was requested by
the user, and it outputs the pass phrase request to stderr without
terminating newline character.
It _would_ be possible to workaround this issue in ConnMan OpenConnect
plugin by attempting to read from stderr whenever it has some bytes to
read. But the non-interactive setting should be respected by other parts
of OpenConnect as well.
This is I get in the logs:
openconnect[2772]: POST https://ocserv.local/
openconnect[2772]: Connected to ocserv.local:443
openconnect[2772]: Failed to decrypt PKCS#12 certificate file
And because of non-newline terminated output to stderr in
non-interactive mode ("Enter PKCS#12 pass phrase") a deadlock happens
until OC times out and quits (in our environment, it takes minutes).
After stopping or restarting connman-vpnd rest of the content is in logs:
openconnect[2772]: User input required in non-interactive mode
openconnect[2772]: Loading certificate failed. Aborting.
connman-vpnd[520]: vpn/plugins/openconnect.c:io_channel_err_cb()
openconnect: Enter PKCS#12 pass phrase:
openconnect[2772]: Failed to open HTTPS connection to ocserv.local
connman-vpnd[520]: vpn/plugins/openconnect.c:io_channel_err_cb()
openconnect: ***
The issue above can be solved by not using --syslog for OpenConnect when
PKCS mode is in use for authentication. This is not included in the
current patches, but I'm thinking of how to overcome the issue. By
disabling --syslog with PKCS to get the information about decryption
failure or to find a way to fix OpenConnect.
Pondering this gave me the idea that the ConnMan OpenConnect plugin
request for the PKCS pass phrase should be reactive instead of having it
as mandatory setting to be queried via VPN agent at startup. I can make
changes to support prompting the pass phrase from VPN agent when the
question arrives to input the password.
David: would you have an idea how to solve that OpenConnect
non-interactive mode issue? I've tried to find a solution for this issue
but to no avail. Shall we continue this discussion @
https://gitlab.com/openconnect/openconnect ?
Sincerely,
Jussi Laakkonen
On 10/2/19 10:49 PM, David Woodhouse wrote:
> Hm, this seems very wrong. Files which happen to be PKCS#12 should be
> treated absolutely identically to files which happen to be PKCS#1 or PKCS#8.
>
> See http://david.woodhou.se/draft-woodhouse-cert-best-practice.html
>
> On 2 October 2019 15:16:48 BST, Jussi Laakkonen
> <[email protected]> wrote:
>
> Add new OpenConnect VPN agent parameters to the API documentation.
> Following are added:
> Name Requirement OC authentication type
> OpenConnect.PKCS12ClientCert informational pkcs12
> OpenConnect.PKCS12Password mandatory pkcs12
> ------------------------------------------------------------------------
> doc/vpn-agent-api.txt | 9 +++++++++
> 1 file changed, 9 insertions(+)
>
> diff --git a/doc/vpn-agent-api.txt b/doc/vpn-agent-api.txt
> index 26c732d1..fcb0e9e1 100644
> --- a/doc/vpn-agent-api.txt
> +++ b/doc/vpn-agent-api.txt
> @@ -85,6 +85,15 @@ Fields string Username
> Return the OpenConnect cookie value that is
> used for
> authenticating the VPN session.
>
> + string OpenConnect.PKCS12ClientCert
> +
> + Informational field containing a PKCS#12 URL or a path
> + name for the PKCS#12 client certificate.
> +
> + string OpenConnect.PKCS12Password
> +
> + Password for decrypting PKCS#12 client certificate.
> +
> string OpenConnect.ServerCert
>
> Return the OpenConnect server hash used to
> identify
>
>
> --
> Sent from my Android device with K-9 Mail. Please excuse my brevity.
------------------------------
Subject: Digest Footer
_______________________________________________
connman mailing list -- [email protected]
To unsubscribe send an email to [email protected]
------------------------------
End of connman Digest, Vol 48, Issue 5
**************************************
