On Jan 13, 2017 6:16 AM, "David Woodhouse" <dwmw2 at infradead.org> wrote:
>
> On Wed, 2017-01-11 at 20:01 -0800, Daniel Lenski wrote:
> >
> > Does anyone else use a Juniper VPN that supports *SSL* DEFLATE
> > compression? Does it return the same config value? Any hint that I'm
> > on the right track would be appreciated.
>
> If it really means SSL deflate, then that's negotiated as part of the
> SSL handshake. Can you capture and show the SSL session establishment?
>
> Try adding COMP-ALL to the GnuTLS priority string for OpenConnect...
>
Hmm, that's an interesting idea. I thought I was looking for
compression at the level of the (inner) IP packets exchanged over the
oNCP tunnel, not at the (outer) TLS transport.
Adding +COMP-ALL doesn't seem to do anything, however, as confirmed by
gnutls-cli. This connects without compression:
$ gnutls-cli -V --priority "NORMAL:+COMP-ALL" vpn.server.com
Taking the observed TLS connection settings and forcing +COMP-DEFLATE
simply results in a failed handshake:
$ gnutls-cli -V --priority
"NONE:+VERS-TLS1.2:+RSA:+AES-128-CBC:+SHA256:+COMP-DEFLATE"
b2b-portal.renesas.com
It appears that whatever the DEFLATE compression is, it isn't standard
transport level compression. Which is in keeping with what I've
learned from oncp.c ?
/*
* This protocol is horrid. There are encapsulations within
* encapsulations within encapsulations. Some of them entirely
* gratuitous.
-Dan
