Connecting to anyconnect vpn - system verification

[Zbyněk Kačer]

Daniel Lenski wrote:
> I'm afraid tuning parameters does not help at all. I unsuccessfully
>> tried various combinantions.
>> Then I dumped the /opt/cisco/anyconnect/bin/vpnui traffic, tried what
>> the official client sends and still no success.
> Hmmm. So you can see all (or almost all) of the traffic between the
> official client and the server, and you see NO differences between
> what OpenConnect sends and what the official clients send…?
>
>> What can I do more? What to dump?
> It's quite difficult to say without seeing some of this traffic and
> comparing carefully. It sounds like you've already read
> https://www.infradead.org/openconnect/mitm.html, and have a good idea
> of how to capture the traffic from the official client.
>
>> I'm able to dump (SSLKEYLOGFILE) ui's traffic and partly also the
>> vpnagentd's traffic but there are still some tls streams unreadable.
> Any idea about the *timing* or *quantity* of those TLS streams which
> you can't see, relative to other requests which you can see?
>
> Dan
>
Hi,
so far I'm able to decode the data from the original client ui (both 
SSLKEYLOGFILE and mitmproxy) but I'm not able to decode the data from 
the vpnagentd service - it ignores SSLKEYLOGFILE and refuses the mitmproxy.

The login attempt (3 POSTS) are however sent by the ui, so I compared 
them and it's almost the same: http://stuff.pitris.info/posts.tar.xz 
(side-by-side diff looks best). Pls check if you see some difference 
which might matter.
Also anyconnect (apart from openconnect) uses one tcp stream instead of 
connecting for every POST but I guess this does not matter.

After those 3 POSTS anyconnect opens another tcp channel to the gw 
(vpnagentd - I cannot decrypt so far) and shares some data. Also at the 
same time opens the DTLS channel.
After some time (seconds) the DTLS channel is closed and another one is 
opened - I think this is the switch from "limited vpn access" to "full 
access". The tcp channel remains open until I disconnect.

I will now try to decrypt the tcp channel - there must be something 
useful inside. But so far it refuses to use mitmproxy.

Zb.