Re: Use OpenSSL socket as a normal socket
Ok, I understand your point now. But it sounds strange to me accepting on the same port incoming SSL protected data and native TCP unprotected socket... I am curious what other can tell about that. Le 09/11/2012 14:19, Derek Cole a écrit : Well that would still require an SSL handshake right? My client that sends the unencrypted traffic knows nothing of SSL at all, and I can't modify it, so it is just coming in a normal TCP stream. On Fri, Nov 9, 2012 at 6:44 AM, Michel wrote: Hi, Perhaps I misunderstand you, but wouldn't it be easier to just choose eNULL cipher when no encryption is needed ? Le 09/11/2012 06:08, Derek Cole a écrit : Hello, I have a server running that I am accepting both SSL and non SSL traffic. Currently I check the traffic first and if the first part of the TCP data looks like an SSL header, I send it off to an OpenSSL socket to be read. If it's plaintext, I just read it right there on that socket. Is it possible to skip the SSL header check and just send all traffic to an SSL socket, and reliably be able to read the traffic regardless whether it's encryprted or not? just to be clear, I do have the SSL context set up properly and don't have a problem reading it, it's just annoying that I Have to check my traffic in a separate step, and send it down the flow path of SSL if it's encrypted. Thanks __**__**__ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Use OpenSSL socket as a normal socket
I'd say you're doing it the right way now; traditionally services that want to support SSL/TLS and not on the same port use the STARTTLS methodology, starting with a plain connection. Since you can't modify your client, you're stuck buffering a bit of data at the beginning to sniff it it looks like SSL/TLS or plain (based on whatever your plain client normally sends, which hopefully cannot overlap with SSL/TLS hello) and passing it on to SSL afterwards. You can use a BIO_s_mem() for this purpose if you don't want to write your own BIO to read from your buffer list, so that the buffering is semi-transparent to the SSL instance, though I suspect that's what you're doing already. k On Fri, Nov 9, 2012 at 2:19 PM, Derek Cole wrote: > Well that would still require an SSL handshake right? My client that sends > the unencrypted traffic knows nothing of SSL at all, and I can't modify it, > so it is just coming in a normal TCP stream. > > > > On Fri, Nov 9, 2012 at 6:44 AM, Michel wrote: >> >> Hi, >> >> Perhaps I misunderstand you, but wouldn't it be easier to just choose >> eNULL cipher when no encryption is needed ? >> >> Le 09/11/2012 06:08, Derek Cole a écrit : >> >>> Hello, >>> >>> I have a server running that I am accepting both SSL and non SSL traffic. >>> Currently I check the traffic first and if the first part of the TCP data >>> looks like an SSL header, I send it off to an OpenSSL socket to be read. >>> If >>> it's plaintext, I just read it right there on that socket. >>> >>> Is it possible to skip the SSL header check and just send all traffic to >>> an >>> SSL socket, and reliably be able to read the traffic regardless whether >>> it's encryprted or not? >>> >>> just to be clear, I do have the SSL context set up properly and don't >>> have >>> a problem reading it, it's just annoying that I Have to check my traffic >>> in >>> a separate step, and send it down the flow path of SSL if it's encrypted. >>> >>> Thanks >>> >> >> __ >> OpenSSL Project http://www.openssl.org >> User Support Mailing Listopenssl-users@openssl.org >> Automated List Manager majord...@openssl.org > > __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Use OpenSSL socket as a normal socket
Well that would still require an SSL handshake right? My client that sends the unencrypted traffic knows nothing of SSL at all, and I can't modify it, so it is just coming in a normal TCP stream. On Fri, Nov 9, 2012 at 6:44 AM, Michel wrote: > Hi, > > Perhaps I misunderstand you, but wouldn't it be easier to just choose > eNULL cipher when no encryption is needed ? > > Le 09/11/2012 06:08, Derek Cole a écrit : > > Hello, >> >> I have a server running that I am accepting both SSL and non SSL traffic. >> Currently I check the traffic first and if the first part of the TCP data >> looks like an SSL header, I send it off to an OpenSSL socket to be read. >> If >> it's plaintext, I just read it right there on that socket. >> >> Is it possible to skip the SSL header check and just send all traffic to >> an >> SSL socket, and reliably be able to read the traffic regardless whether >> it's encryprted or not? >> >> just to be clear, I do have the SSL context set up properly and don't have >> a problem reading it, it's just annoying that I Have to check my traffic >> in >> a separate step, and send it down the flow path of SSL if it's encrypted. >> >> Thanks >> >> > __**__**__ > OpenSSL Project http://www.openssl.org > User Support Mailing Listopenssl-users@openssl.org > Automated List Manager majord...@openssl.org >
Re: Use OpenSSL socket as a normal socket
Hi, Perhaps I misunderstand you, but wouldn't it be easier to just choose eNULL cipher when no encryption is needed ? Le 09/11/2012 06:08, Derek Cole a écrit : Hello, I have a server running that I am accepting both SSL and non SSL traffic. Currently I check the traffic first and if the first part of the TCP data looks like an SSL header, I send it off to an OpenSSL socket to be read. If it's plaintext, I just read it right there on that socket. Is it possible to skip the SSL header check and just send all traffic to an SSL socket, and reliably be able to read the traffic regardless whether it's encryprted or not? just to be clear, I do have the SSL context set up properly and don't have a problem reading it, it's just annoying that I Have to check my traffic in a separate step, and send it down the flow path of SSL if it's encrypted. Thanks __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Use OpenSSL socket as a normal socket
Hello, I have a server running that I am accepting both SSL and non SSL traffic. Currently I check the traffic first and if the first part of the TCP data looks like an SSL header, I send it off to an OpenSSL socket to be read. If it's plaintext, I just read it right there on that socket. Is it possible to skip the SSL header check and just send all traffic to an SSL socket, and reliably be able to read the traffic regardless whether it's encryprted or not? just to be clear, I do have the SSL context set up properly and don't have a problem reading it, it's just annoying that I Have to check my traffic in a separate step, and send it down the flow path of SSL if it's encrypted. Thanks
Re: openssl socket
On 12/29/2010 1:11 AM, Esimorp E wrote: Hi all, I tried changing the one-to-one socket type in OpenSSL to one-to-many by changing SOCK_STREAM to SOCK_SEQPACKET and it compiled fine but while trying to run other program on it I had the following error: bss_dgram.c(236): OpenSSL internal error, assertion failed: ret >= 0 Please, can anyone tell me how to solve this problem. Change the socket type back to SOCK_STREAM or implement all the code necessary to handle the semantic differences between these socket types. DS __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
openssl socket
Hi all, I tried changing the one-to-one socket type in OpenSSL to one-to-many by changing SOCK_STREAM to SOCK_SEQPACKET and it compiled fine but while trying to run other program on it I had the following error: bss_dgram.c(236): OpenSSL internal error, assertion failed: ret >= 0 Please, can anyone tell me how to solve this problem. Regards, Esimorp.
Memory growth in OpenSSL socket server
I have a simple server under WinXP that creates a thread for a 'listener' and spins off a new thread for each incoming client. Im limiting access to one client at a time at this point so it blocks on the listener until the client is closed. Im using a self-signed certificate for the server. The client is (for now) on the same machine and connects via Perl using IO::Socket::SSL. Im watching the memory of the server using 'perfmon.exe' using the 'private bytes' for the process. Im also watching via 'TaskMgr'. The Perl code opens a connection, sends and then receives 3 different blocks of data. The size ranges from 10 bytes to 1 bytes. The 'test' loops this perl file with a second perl file that runs it, sleeps for 3 seconds and then repeats. The data is the same each time. What Im seeing: For the first three 'passes' the server memory grows by about 10% each time and then stabilizes. From there it remains stable for from 1-10 (~) passes and then grows by ~10%. Sometimes it will remain at this new level sometimes it will return to the previous. If it remains at either level it will do so for 1-10(~) passes and then jump up again. Ive tested this for > 3000 passes and have seen the same behavior repeating. It looks like some sort of buffer or cache is being filled and so more memory is allocated. Nothing shows up as a memory leak though so someone is freeing the space when the app exits. Unf this code will end up in a service so there isn't a guarantee as to when the space will get freed. I will also be sending vastly more information so the buffer problem will be a large problem. If I run the same code sans SSL it doesn't have this problem. What I have tried: (at SSL_ctx creation) SSL_CTX_set_session_cache_mode(m_ctx, SSL_SESS_CACHE_OFF); SSL_CTX_sess_set_cache_size(m_ctx, 1); (between each thread creation) SSL_CTX_flush_sessions(ctx, 0); using: OpenSSL 0.9.8g. Visual Studio 7 Win XP Perl 5.8.8 What am I missing? What am I doing wrong? -- View this message in context: http://www.nabble.com/Memory-growth-in-OpenSSL-socket-server-tp15280493p15280493.html Sent from the OpenSSL - User mailing list archive at Nabble.com. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
RE: OpenSSL, socket and Kernel
> Hello, > > oh sorry, i'm using linux! the secure network connection must be > implemented in a modified linux-kernel! > still i'm searching for a possibility like i can realize it ... till > present i still have no experiences with openssl-programing. > therefore, it is an advantage to known whether it is possible or not. > > greets > Frank It's possible that you could do this with a Broadcom Cryptonet adapter. This supports most of SSL natively and has support in the Linux kernel. Oherwise, you'd basically have to port most of OpenSSL into Linux kernel space. But before you even started, you'd need a concept on how this was supposed to work. Where would the keys come from? Or are you looking for just a HTTPS client? Bluntly, it's hard to conceive of any reason this would be a good idea to do in kernel space. Not understanding your requirements, I cannot advise you to follow my advice. ;) DS __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: OpenSSL, socket and Kernel
Why not use IPsec. Why does it have to be in the kernel? It's hard to see what the security trade-offs are that make this necesary. -- Rich Salz Chief Security Architect DataPower Technology http://www.datapower.com XS40 XML Security Gateway http://www.datapower.com/products/xs40.html XML Security Overview http://www.datapower.com/xmldev/xmlsecurity.html __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
RE: OpenSSL, socket and Kernel
> > There's a lot of different things you could mean by > >"kernel-socket-network-connection". Can you clarify? > > > > If you're talking about using SSL to secure network > >connections that take > >place purely in kernel space, yes, you can do this. It's fairly tedious > >because you still want to do the asymmetric cipher in user space. > > > > DS > oh thats bad, because the complete network connection must be realized > by the kernel. the user should have to do nothing with it. > is there another way to realize it without using the user space ? You really should get a security expert who is familiar with your requirements to comment in more detail. You didn't mention what operating system you're talking about, but the situation on Windows is totally different from the situation on UNIXes. If you really want all the crypto in the kernel, you probably should be looking at platform-specific solutions. Linux, for example, has cryptoapi. http://www.kerneli.org/index.phtml Windows has SSPI. http://msdn.microsoft.com/library/default.asp?url=/library/en-us/security/se curity/sspi_model.asp Not knowing what your requirements are, and somewhat baffled by why anyone would want to put something that so obviously belongs in user space into the kernel, it's hard for me to know what to advise you. DS __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: OpenSSL, socket and Kernel
There's a lot of different things you could mean by "kernel-socket-network-connection". Can you clarify? If you're talking about using SSL to secure network connections that take place purely in kernel space, yes, you can do this. It's fairly tedious because you still want to do the asymmetric cipher in user space. DS oh thats bad, because the complete network connection must be realized by the kernel. the user should have to do nothing with it. is there another way to realize it without using the user space ? thx Frank __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
RE: OpenSSL, socket and Kernel
> Hi, > > is it possible to use openssl in a kernel-socket-network-connection ? > > thx There's a lot of different things you could mean by "kernel-socket-network-connection". Can you clarify? If you're talking about using SSL to secure network connections that take place purely in kernel space, yes, you can do this. It's fairly tedious because you still want to do the asymmetric cipher in user space. DS __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
OpenSSL, socket and Kernel
Hi, is it possible to use openssl in a kernel-socket-network-connection ? thx -- Frank __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
