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. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html