Re: openssl-users: DKIM, DMARC and all that jazz, and what it means to us

2019-02-15 Thread Richard Weinberger
Am Freitag, 15. Februar 2019, 16:03:42 CET schrieb Richard Levitte:
> So, to mitigate the problem, we've removed all extra decoration of the
> messages, i.e. the list footer that's usually added and the subject
> tag that indicates what list this is (I added the "openssl-users:"
> that you see manually).

Hmm, and as side effect you have forcefully re-enabled mail delivery for all
mailinglist members?
I disable mail delivery usually and read mails via gmail.

Thanks,
//richard




Re: [openssl-users] DTLS-over-UDP client example

2018-09-18 Thread Richard Weinberger
On Tue, Sep 18, 2018 at 9:18 AM 
wrote:> Unfortunelly, it's exactly this example which I use. You have
pointed on slightly different version,
> but all difference is:
>
> SSL_CTX_set_cookie_verify_cb(ctx, _cookie);
> instead of
> SSL_CTX_set_cookie_verify_cb(ctx, verify_cookie);
>
> ctx = SSL_CTX_new(DTLS_client_method());
> instead of
> ctx = SSL_CTX_new(DTLSv1_client_method());
>
>
> I have tryed it, works exactly the same.
>
> In both versions, on client side cipher_list is:
> SSL_CTX_set_cipher_list(ctx, "eNULL:!MD5");
>
> With such list it works, but without encoding (data send in cleartext, 
> connection established as  Cipher: NULL-SHA)
>
> and if I remove eNULL on client side, it doesn't connect - server wait repeat 
> of client cookue forever.
>
> At the same time,  "openssl s_client -dtls1   ..." connects fine, with 
> Cipher: AES256-SHA

Then debug why the server is ignoring the client request.
OpenSSL has good debug output, in worst case add new prints...

-- 
Thanks,
//richard
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users


Re: [openssl-users] DTLS-over-UDP client example

2018-09-17 Thread Richard Weinberger
On Thu, Sep 13, 2018 at 3:51 PM  wrote:
> I tryed to dig inside openssl s_client source code, but it's really too 
> complex for me, it seems like s_client doesn't use
> SSL_connect, instead, using more low-level functions.
>
>
> So, does anybody have any simple client-side implementation of DTLS over UDP 
> connection?

https://web.archive.org/web/20150806185102/http://sctp.fh-muenster.de:80/dtls/dtls_udp_echo.c
... is a good example.

In case you are on 1.1.x, please also see:
https://mta.openssl.org/pipermail/openssl-users/2018-August/008498.html

OpenSSL badly regressed in 1.1.x wrt. DTLS.

-- 
Thanks,
//richard
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users


Re: [openssl-users] Multi client DTLS server on OpenSSL 1.1.x broken?

2018-08-15 Thread Richard Weinberger
Philip,

On Wed, Aug 15, 2018 at 11:36 PM Philip Prindeville
 wrote:
> Have a look at:
>
> http://www.wangafu.net/~nickm/libevent-book/Ref6a_advanced_bufferevents.html
>
> you don’t need a dedicated thread per connection.

I know. I have already full blown single threaded event loop that
works fine with OpenSSL 1.0.x.

> See the section “Bufferevents and SSL”
>
> You can create an SSL context and then bind a connection listener to it.
>
> If the library doesn’t specifically handle the case of DTLS (I know it 
> handles SSL and TLS), then it shouldn’t be too hard to cobble something 
> together and even get it upstreamed.

Well, it still seems to miss the fact that DTLSv1_listen() regressed in 1.1.x.
I really don't see how layering libevent into my application should help here.

-- 
Thanks,
//richard
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users


Re: [openssl-users] Multi client DTLS server on OpenSSL 1.1.x broken?

2018-08-15 Thread Richard Weinberger
Philip,

Am Mittwoch, 15. August 2018, 21:36:30 CEST schrieben Sie:
> 
> > On Aug 11, 2018, at 9:22 AM, Richard Weinberger  wrote:
> > 
> > Hi!
> > 
> > I have a hard time figuring how to write a DTLS UDP server that supports 
> > multiple
> > clients. My dummy single user server works fine.
> > 
> > To support multiple clients I tried two approaches:
> > 1. singled threaded async IO, preferred since I have to deal with many 
> > clients
> > 2. multi threaded, one thread per client
> > 
> > Both approaches seem to be doomed for the very same reason, namely that
> > DTLSv1_listen() does peek into the kernel queue and does not consume
> > the client hello from the UDP socket.
> > 
> > Both loop around DTLSv1_listen() and as soon the function returns > 0 a new
> > socket for the client is created using bind/connect and the client address
> > as returned by DTLSv1_listen().
> > 
> > This client socket is then passed to a new thread or feed into the event 
> > loop.
> > In both cases the client hello is still in the queue of the server socket
> > and the program will over and over create new client sockets.
> > 
> > After searching the web for examples I've found this thread[0], where the 
> > approaches
> > I tried are advertised.
> > In [1] the demo server at [3] is suggested as good example.
> > 
> > dtls_udp_echo.c from [3] does exactly what I did in my 2nd approach, and it 
> > fails in
> > the same way.
> > As soon one client connects, it creates over and over new sockets until it 
> > dies due
> > to too many open files.
> > 
> > After digging a bit into the source it looks to me like since commit [3],
> > DTLSv1_listen() assumes that you re-use the same socket for the new client.
> > Which makes supporting multiple clients impossible.
> > 
> > Given that I'm not an OpenSSL DTLS expert I still hope I miss something.
> > Can you please help me to figure what the correct approach for multiple 
> > clients is?
> > 
> > Thanks,
> > //richard
> 
> 
> Have you tried using Libevent?  It supports SSL/TLS/DTLS connections.

Can you please explain? I fear I miss something.

Libevent seems to be able to deal with OpenSSL BIO objects.
But how is it supposed to help me with the DTLSv1_listen() issue?

A quick grep on the Libevent sources does not show calls to DTLSv1_listen()
and I don't think that it is open coding it. At least I hope so.

The problem I see is not about event processing, it is about OpenSSL 1.1.x's
re-write of DTLSv1_listen().

Thanks,
//richard


-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users


[openssl-users] Multi client DTLS server on OpenSSL 1.1.x broken?

2018-08-11 Thread Richard Weinberger
Hi!

I have a hard time figuring how to write a DTLS UDP server that supports 
multiple
clients. My dummy single user server works fine.

To support multiple clients I tried two approaches:
1. singled threaded async IO, preferred since I have to deal with many clients
2. multi threaded, one thread per client

Both approaches seem to be doomed for the very same reason, namely that
DTLSv1_listen() does peek into the kernel queue and does not consume
the client hello from the UDP socket.

Both loop around DTLSv1_listen() and as soon the function returns > 0 a new
socket for the client is created using bind/connect and the client address
as returned by DTLSv1_listen().

This client socket is then passed to a new thread or feed into the event loop.
In both cases the client hello is still in the queue of the server socket
and the program will over and over create new client sockets.

After searching the web for examples I've found this thread[0], where the 
approaches
I tried are advertised.
In [1] the demo server at [3] is suggested as good example.

dtls_udp_echo.c from [3] does exactly what I did in my 2nd approach, and it 
fails in
the same way.
As soon one client connects, it creates over and over new sockets until it dies 
due
to too many open files.

After digging a bit into the source it looks to me like since commit [3],
DTLSv1_listen() assumes that you re-use the same socket for the new client.
Which makes supporting multiple clients impossible.

Given that I'm not an OpenSSL DTLS expert I still hope I miss something.
Can you please help me to figure what the correct approach for multiple clients 
is?

Thanks,
//richard

P.s: I'm on Linux, OpenSSL 1.1.0h, but tried as OpenSSL git as of today.

[0] https://mta.openssl.org/pipermail/openssl-users/2018-April/007861.html
[1] https://mta.openssl.org/pipermail/openssl-users/2018-April/007864.html
[2] 
https://web.archive.org/web/20150806185102/http://sctp.fh-muenster.de:80/dtls/dtls_udp_echo.c
[3] 
https://github.com/openssl/openssl/commit/e3d0dae7cf8363ca462ac425b72c7bb31c3b4b7a
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users


Re: [openssl-users] Compiling OpenSSL 1.1.0e with AF_ALG engine

2017-02-22 Thread Richard Weinberger
Am 22.02.2017 um 12:24 schrieb David Oberhollenzer:
> Sorry, never mind. After taking a closer look at the source code I saw
> that there are further compile time and run-time kernel version
> checks in e_afalg.c. I adjusted the version number and got that to
> work now.

Well, why does the afalg engine depend on Linux 4.1?
AF_ALG is part of Linux since 2.6.38.

Furthermore it is not clear to me why the Kernel version is being
checked during the build.
What if I build on an older kernel?
Does your build system offer a config option for that?

Thanks,
//richard

-- 
sigma star gmbh - Eduard-Bodem-Gasse 6 - 6020 Innsbruck - Austria
ATU66964118 - FN 374287y
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users