[PULL request] distinguish between different rekey methods

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Thu, 2014-02-13 at 22:53 -0800, Kevin Cernekee wrote:
> If I set method "ssl" or "new-tunnel", the result is the same:

> X-CSTP-Rekey-Method: new-tunnel
> X-DTLS-Rekey-Time: 240
> 
> This could be a bug, or maybe it means the "ssl" method isn't
> implemented on this firmware version.

Perhaps the SSL renegotiation method got deprecated around the time of
CVE-2009-3555.


> FWIW, I still need this patch to prevent DTLS from going out to lunch
> after CSTP reconnections:
> 
> https://github.com/cernekee/openconnect/commit/a53877ea22a546b12a9e2c30561fbd38c695532e

I broke that in (and around) commit e35b71cb1. Any chance of an updated
version, please? It'll take me at least a day to test here...

> Every time I reconnect CSTP, I receive a new DTLS session ID from the ASA.

Hm, that used *not* to be the case as long as we didn't generate a new
master-secret. We have logic in start_cstp_connection() to regenerate
vpninfo->dtls_secret only if a DTLS rekey is imminent.

Can you add a log message when it's regenerating the secret, and/or just
comment it out to make sure it *never* does, and confirm the behaviour?

-- 
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/20140214/b1880058/attachment.bin>


[Index of Archives]     [Linux Samsung SoC]     [Linux Rockchip SoC]     [Linux Actions SoC]     [Linux for Synopsys ARC Processors]     [Linux NFS]     [Linux NILFS]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]


  Powered by Linux