Andreas Hartmann wrote:
That's right. But:
1. There could be a security issue with parallel handled users during initial login, because they probably have all the same empty session id's at the same time.
Well... that's an OpenSSL bug. We can check for it and try to avoid the issue. But as I said, the session_id is managed by OpenSSL.
2. Session handling does definitely not work at this point (I tried to find the reason today but couldn't get it yet).
Uh... for *you*. It works for me, and others.
Why should I believe that it works error free at the other places in freeradius?
I have no idea what you mean by that. It really sounds like a veiled accusation that the server is somehow broken in unknown ways.
3. You are right, that there are probably no security issues with rejected users. But why are you sure, that every session-id you get, does belong to the user you think that it belongs to? It could be the data from another user too.
Blame OpenSSL. I really can't be any clearer than that. When *I* use OpenSSL, the session key isn't empty.
4. I can't say, if it's an exploitable scenario. May be - may be not.
FUD.
The session-handling in freeradius does not allways work as expected and until now the cause for the not allways working session-handling is unknown.
Nonsense. It's an OpenSSL bug, and you have been told repeatedly it's an OpenSSL bug. Calling it "unknown" is being stupid.
Or in other words: The session-handling works not predictable (sometimes it works as expected - sometimes not - but you can't define "sometimes" - or I didn't found it yet). Unpredictable behavior and security is a contradiction.
You're repeating your fears to the point of being ridiculous.
It's your application that suffers - it's not openssls one. Therefore I can't understand why you don't set everything to get a real solution?
Because no one else has reported this, and I don't want to track down bugs in OpenSSL. It's really not my problem.
And no, I don't want to bash you. I'm willing to help, but I need your support to try to understand what's going on.
What part of my message is unclear? It's an OpenSSL bug.
I am willing to help you to find and fix the problem - even if it is not a bug in freeradius. It is all the same to me, if it's a bug in openssl or in freeradius. I do have just one goal: freeradius should work predictable in that case. That's all and this goal can't be bad for you!
Thanks for thinking of our goals.
I can't file a bug for openssl. What should I wrote? The session handling in openssl does not work with freeradius?
And I can file a bug with more information? I can't reproduce the problem, so I have *less information than you. Stop being lazy, and go file an OpenSSL bug. If you care to fix the problem, this is the *only* way to solve it.
They will say: ok, openssl has been patched for EAP
Nonsense.
or they will ask detailed things about the handling of SSL in freeradius. I think that you are the best person to answer these questions!
Nonsense. I can't reproduce the problem, and the code is publicly available. *You* are the best person to reproduce the problem.
BTW: During my investigations today, I detected, that the defined callback cbtls_new_session never gets called during an initial session. That corresponds to the thing, that I can't see any session-ID during initial login.
Well... the callback is controlled by oh... let me guess.. *OPENSSL*.
I would like to know, why the client suddenly has a session-ID at resumption time? Where do they come from?
Perhaps you should try asking *THE OPENSSL PEOPLE* ? If you have a patch for FreeRADIUS, supply it. But it is inappropriate to ask *us* to track down and fix an *OpenSSL* issue that only *you* can see. Alan DeKok.