Hi Laurens,
>>> openssl:
>>> ...
>>> DH:ECP_256
>>> ...
>>
>> Ah yes. It's because the default IKE proposal in versions before 5.4.0
>> listed ECP_256 after MODP_2048 and the server always preferred its own
>> proposals (this can be changed with the upcoming 5.5.0 release). So it
>> insists
Hi folks,
I would highly appreciate some feedback about this. Is it
unreasonable to expect that the IPsec payload should not be
affected by the slow updown script?
All the road warrior Macs and Iphones do VPN-on-demand.
Currently the IPsec connection succeeds, but the DNS lookup
(the "demand" in
Hello Harald,
Your objections from your last email are wrong.
Adding a global rule with the policy match does not introduce any possible
vulnerability.
> The problem is that eth0 has been reused for the decoded
> traffic. The iptables entries about eth0 affect both
> the connection to the intern
Hi All,
I am new to strongswan and trying to protect host-host traffic using ipsec
tunnel mode. However I observe that only the traffic between endpoints are
protected and not complete traffic.
*Strongswan Version*: Linux strongSwan U5.3.2/K3.12.19-rt30
*Topology*:
>>> --- GW_A <---
We noticed some text in the code that suggests that TBOOT isn’t fully
implemented yet. Is there a plan to support Intel TXT/TBOOT (PCRs 17 and 18)?
The current code looks like we can only populate the config file (it doesn’t
appear to be pulling from the actual PCR17/18 on the TPM).
--
Glen W
Hi Glen,
the problem is that I currently haven't got a hardware platform
I could test TBOOT based on TXT with. Therefore I cannot complete the
development of the TBOOT measurements.
Best regards
Andreas
On 05.07.2016 16:55, Wiley, Glen wrote:
We noticed some text in the code that suggests tha
