>
> I use interactive debuggers when I can, and I find that debugging
> windows on windows and linux on linux works best for me. The M$ tools
> have their flaws, but they do have excellent links to API documentation
> & system RTL's sources. For debugging the cryptoapi interface, that
>
On 24-Apr-14 04:17, Gert Doering wrote:
I do run these on a windows 7 machine, but can't reconfigure them just
for debugging OpenVPN.
No, I wasn't suggesting that you do that, I was just trying to clarify
what build options we have.
I find "add msg() calls, build on linux, run on windows,
> Hi,
>
> On Thu, Apr 24, 2014 at 04:05:20AM -0400, Timothe Litt wrote:
>>> Uh, this is a double misinformation :-)
>> It's good to know that cross-compiling is an option, though
>> cross-debugging (e.g. with an interactive debugger) can be an adventure too.
>>
>> Source of my comment was:
>>
>>
Hi,
On Thu, Apr 24, 2014 at 04:05:20AM -0400, Timothe Litt wrote:
> >Uh, this is a double misinformation :-)
> It's good to know that cross-compiling is an option, though
> cross-debugging (e.g. with an interactive debugger) can be an adventure too.
>
> Source of my comment was:
>
>
Uh, this is a double misinformation :-)
It's good to know that cross-compiling is an option, though
cross-debugging (e.g. with an interactive debugger) can be an adventure too.
Source of my comment was:
http://community.openvpn.net/openvpn/wiki/BuildingOnWindows, which says
his new build
Hi,
On Wed, Apr 23, 2014 at 07:21:48PM -0400, Timothe Litt wrote:
> As I can't build the windows client (it's really annoying that it
> requires commercial tools), further debug will need help from folks who can.
Uh, this is a double misinformation :-)
- you can build with MSVC, and you can
On 23/04/2014 18:22, Timothe Litt wrote:
I don't see that cryptoapi.c has been updated to work with TLS 1.2.
Yes, just came to the same conclusion.
Long-term the key-loaders need to get updated.
Maybe short-term the options that invoke them could force NO_TLSv_1_2...
That would make things
I don't see that cryptoapi.c has been updated to work with TLS 1.2.
Yes, just came to the same conclusion.
Long-term the key-loaders need to get updated.
Maybe short-term the options that invoke them could force NO_TLSv_1_2...
That would make things work for most people in the short term.
On
On 23/04/2014 17:21, Timothe Litt wrote:
On 23-Apr-14 16:06, Steffan Karger wrote:
I generated a matching pair of traces of the failure (client and server)
& posted a summary.
Let me know if you would like the full traces.
Sent off-list.
I've been trying to reproduce the error. I grabbed my
On 23-Apr-14 16:06, Steffan Karger wrote:
I generated a matching pair of traces of the failure (client and server)
& posted a summary.
Let me know if you would like the full traces.
Sent off-list.
I've been trying to reproduce the error. I grabbed my spare pi from the
desk drawer and built
Hi,
On 23-04-14 17:36, Timothe Litt wrote:
> Just to confirm that the issue is 1.2, not the negotiation:
>
> I added an unconditional
> sslopt |= SSL_OP_NO_TLSv1_2;
> in tls_ctx_set_options.
>
> With this (and the context initialized to SSL_v23_*_method, so we
> negotiate), the tunnel
Hi,
On Wed, Apr 23, 2014 at 01:27:19PM -0400, Timothe Litt wrote:
> >now - does that sound like it could be the problem? The initial handshake
> >packet "under some conditions" (like: the local OpenSSL build having
> >more available ciphers, depending on how it was built) being too big,
>
Gert,
while cycling home from $paidwork
Cycling while thinking about TLS might be as bad as texting while driving...
now - does that sound like it could be the problem? The initial handshake
packet "under some conditions" (like: the local OpenSSL build having
more available ciphers,
Hi,
On Wed, Apr 23, 2014 at 11:36:28AM -0400, Timothe Litt wrote:
> Just to confirm that the issue is 1.2, not the negotiation:
>
> I added an unconditional
> sslopt |= SSL_OP_NO_TLSv1_2;
> in tls_ctx_set_options.
>
> With this (and the context initialized to SSL_v23_*_method, so we
>
On 23-Apr-14 06:56, Steffan Karger wrote:
Hi,
On 04/23/2014 10:10 AM, Gert Doering wrote:
On Tue, Apr 22, 2014 at 10:58:22PM -0400, Timothe Litt wrote:
It does not appear to be the negotiation, rather it's TLS1.2.
This is quite cool, thank you. (I'm not enough of a crypto geek to
make real
This is quite cool, thank you.
You're welcome. I don't like unsolved mysteries, and since I have a
solid reproducer, thought I should do what I can.
Some more. I looked into building on Windows, but the doc says one
needs commercial tools; I'm not going to buy them for this.
However, I
Hi,
On 04/23/2014 10:10 AM, Gert Doering wrote:
> On Tue, Apr 22, 2014 at 10:58:22PM -0400, Timothe Litt wrote:
>> It does not appear to be the negotiation, rather it's TLS1.2.
>
> This is quite cool, thank you. (I'm not enough of a crypto geek to
> make real sense out of it, but it's quite
Hi,
On Tue, Apr 22, 2014 at 10:58:22PM -0400, Timothe Litt wrote:
> It does not appear to be the negotiation, rather it's TLS1.2.
This is quite cool, thank you. (I'm not enough of a crypto geek to
make real sense out of it, but it's quite useful to understand where
it is failing, and I
It does not appear to be the negotiation, rather it's TLS1.2.
I debugged the client hello in OpenSSL - a bit tricky due to the
timeouts, but I established that the server is picking TLS1.2.
I then switched the tls_ctx_{client,server}_new to use
TLSv1_2_{client,server}_method in the call to
19 matches
Mail list logo
