Server certificate hash checking

[David Woodhouse]

On Fri, 2015-01-02 at 23:16 +0200, Nikos Mavrogiannopoulos wrote:
> On Fri, 2015-01-02 at 09:40 +0000, David Woodhouse wrote:
> 
> > > The latter is probably difficult, but printing the hash and key IDs is
> > > probably a good idea. I'll check it.
> > Well, if the luci https service is using the *same* cert as ocserv then
> > presumably it's already been accepted.
> 
> No it is not. I don't think it is a good idea to mix keys for different
> services.

Hm, is there a way for an X.509 certificate to specify which
ports/services it's valid for? We only actually validate the *hostname*,
because I thought that's all there was.

>  It will also not bring much benefit since the luci https
> service is not typically available from the wan side of a router.

Hm, really? I can understand the http service being unavailable but once
a sane password is set, https ought to be fine.

> > It would be nice for openconnect on the desktop to be capable of using
> > Chrome's¹ "I have already accepted this cert" trust status. 
> 
> I don't know what is that. The windows client uses trust on first use
> for server certificates. 

I mean when I've pointed the web browser at it and manually accepted the
certificate, and that fact has been stored in the NSS database. It would
be useful for OpenConnect to be able to *know* that.

I have this in ~/.config/pkcs11/modules/nss.module but it doesn't
suffice:

module: /usr/lib64/libsoftokn3.so
x-init-reserved: configdir='/home/dwmw2/.mozilla/firefox/b8v9tyu0.default' certPrefix='' keyPrefix='' secmod='secmod.db'
trust-policy: yes

> > While I think about the luci https service sharing a cert with ocserv...
> > are we capable of having it share a *socket*? Port 443 is very useful
> > for getting through firewalls/proxies; it would be good to have them
> > both accessible through it.
> 
> The methods to share a port are currently pretty primitive and require a
> service to forward packets like sniproxy does. That would be an overkill
> in a router environment. A superserver which will transfer the socket
> descriptors between the processes would have been nice there, but there
> is no such thing yet.

OK.

> However, since the luci https service is not typically available on the
> wan side, it wouldn't matter much. I think it would be doable to forward
> the 443 from the wan side to ocserv (never tried it though).

Doesn't even need forwarding, does it? It can listen on the WAN IP
address, and the luci service shouldn't be listening on IN{6,}ADDR_ANY
if it only means to be internal.

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