RE: Hiding headers for OpenSSL
On Mon, 2006-08-21 at 11:42 -0700, [EMAIL PROTECTED] wrote: plain text document attachment (RE:) The long version: We run security check software, which makes connections with various services, calls up the header, and then tells us that based upon the version it read in the header, this service has certain vulnerabilities. I just have to say one more thing: You run security check software, and you are asking us for help in reducing the effectiveness of that software? Are you really more concerned with keeping your vulnerabilities secret than in fixing them? We don't now how this software is use. Security scanners (like Nessus) has distributed architecture and agents may be installed on checked systems. In this situation banners are not important because security scanner agent has access to operating system and may exactly check installed patches/versions/... without looking at banners. And next thing: if someone wants to hide his software - he has right for that, of course this is not defence against hackers, but there is nothing bad in that. We know to little of this system/person to judge or even to offend other persons. Live and let to live others. Best regards, -- Marek Marcola [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: Hiding headers for OpenSSL
On Mon, Aug 21, 2006 at 04:15:46PM -0500, Doug Nebeker wrote: The problem is that virtually no legit users will ever look, but the hackers definitely will. I'll admit (being a geek) that I checked once when logging into my banking site for the first time many years ago. So maybe I was 'benefitted' that one time (and my case is definitely not typical), but the hackers could be 'benefitting' over and over with internal knowledge. The same arguments (showing that I'm trustworthy) could be made for posting company network diagrams, physical site security procedures, backup courier, etc, but nobody does that. The risk/reward ratio doesn't justify giving the information out in my opinion. This discussion is useless: * OpenSSL does not disclose its version to attackers coming from the network as the SSL/TLS protocol does not give any version information of the software used (it does give protocol compatibility information needed for interoperability wrt SSLv2, SSLv3 etc) * It is the application using OpenSSL (in this case Apache) disclosing the information. - Please complain to the Apache people. * Both projects OpenSSL and Apache are Open Source projects. If you find anything about it annoying please feel free to make any modification you want. * Meta bullet point: This discussion about version information and security through obscurity has been seen often enough (have a look into the OpenSSH mailing list archives) and it finally leads nowhere. I will therefore not comment wrt my personal point of view. Best regards, Lutz [EMAIL PROTECTED] wrote on 08/21/2006 03:15:33 PM: The OP, however, is right. Why report the version at all to the user of a website? There is no need to let them know you are even running OpenSSL let alone the version being run. I'm not talking about security through obscurity. I'm referring to common sense. Don't tell people what you are running unless it is absolutely necessary for proper operation. Since version information is metadata, it is not necessary for the proper operation of OpenSSL. The only thing it does is waste a few bytes of bandwidth every time someone connects. Just a thought. We've come along way from the time when banks posted their reserve ratios in the window. If you have fixed the latest vulnerabilities, why would you want to keep this a secret from the people you are asking to trust you? And if you have not, what right do you have to keep that secret? The main reason you run SSL is because you are going to ask other people to trust you with their personal data. It comes down to that fundamental question, why should I trust you? If the answer is because you do things securely, fixing vulnerabilities and choosing proven products, why should that need to be a secret? And if a new vulnerability appears and you haven't had a chance to fix it yet, shouldn't I at least have a chance to know that before I trust you with sensitive information? Security through obscurity is wrong for more than just one reason. But a big one is that it robs the people you interoperate with of the chance to judge for themself whether you are trustworthy. They may just find someone else who is more transparent. So here's my primary answer: suppose a new SSL bug is discovered. It's fixed in version Y but not version X. I need to put a million dollar order through to your server. What should I do? Should I not give you the order until I can somehow confirm you have version Y? (Which, according to you, I should never be able to do. So in this case you don't get the order.) Or should I just assume you do, because you're typically on the ball? (Which might not be what you want, depending on what the consequences are to *you* if the data leaks to a competitor.) Why force the people you are asking to trust you into such craziness? Why not reassure them, assuming you do things right. And if you do things wrong, is it really in your interest to dupe people into trusting you. Think long and hard about that -- it may not be. DS __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED] To find out more about Reuters visit www.about.reuters.com Any views expressed in this message are those of the individual sender, except where the sender specifically states them to be the views of Reuters Ltd. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager
TLS1 support in openssl?
Hi, how does openssl 0.9.8b support tls? I went through the code and it looks like tls is just like an alias for SSLv3. Can someone tell me where exactly TLS1 and SSLv3 differ? What are the changes that they will differ in future? Thank you, ~ UrjitDISCLAIMER == This e-mail may contain privileged and confidential information which is the property of Persistent Systems Pvt. Ltd. It is intended only for the use of the individual or entity to which it is addressed. If you are not the intended recipient, you are not authorized to read, retain, copy, print, distribute or use this message. If you have received this communication in error, please notify the sender and delete all copies of this message. Persistent Systems Pvt. Ltd. does not accept any liability for virus infected mails.
Re: TLS1 support in openssl?
Hello, how does openssl 0.9.8b support tls? I went through the code and it looks like tls is just like an alias for SSLv3. Can someone tell me where exactly TLS1 and SSLv3 differ? In general they are very close, but main difference are: - protocol version in messages (SSL3: 0300, TLS1: 0301) - altert protocol messages ( SSL3: 12, TLS1: 23) - message authentication mechanism - key material generation mechanism - CertificateVerify handshake packet calculation - Finished handshake packet calculation What are the changes that they will differ in future? I do not know. Best regards, -- Marek Marcola [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: TLS1 support in openssl?
- Original Message - From: Marek Marcola [EMAIL PROTECTED] To: openssl-users@openssl.org Sent: Tuesday, August 22, 2006 3:41 PM Subject: Re: TLS1 support in openssl? Hello, how does openssl 0.9.8b support tls? I went through the code and it looks like tls is just like an alias for SSLv3. Can someone tell me where exactly TLS1 and SSLv3 differ? In general they are very close, but main difference are: - protocol version in messages (SSL3: 0300, TLS1: 0301) - altert protocol messages ( SSL3: 12, TLS1: 23) - message authentication mechanism - key material generation mechanism - CertificateVerify handshake packet calculation - Finished handshake packet calculation Thank you for the quick reply. So, I guess SSLv3 and TLS are almost identicle as far as encryptions are concerned and TLS differs from SSLv3 in terms of handshake, authentication, key management. If this is correct, then now onwards what should be preffered methods used for SSL_CTX_new() ? Should it be SSLv3 or TLSv1? Any perticular or obvious resons for selecting one over the other? thanks, ~ Urjit DISCLAIMER == This e-mail may contain privileged and confidential information which is the property of Persistent Systems Pvt. Ltd. It is intended only for the use of the individual or entity to which it is addressed. If you are not the intended recipient, you are not authorized to read, retain, copy, print, distribute or use this message. If you have received this communication in error, please notify the sender and delete all copies of this message. Persistent Systems Pvt. Ltd. does not accept any liability for virus infected mails. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: TLS1 support in openssl?
Hello, So, I guess SSLv3 and TLS are almost identicle as far as encryptions are concerned and TLS differs from SSLv3 in terms of handshake, authentication, key management. If this is correct, then now onwards what should be preffered methods used for SSL_CTX_new() ? Should it be SSLv3 or TLSv1? Any perticular or obvious resons for selecting one over the other? For compatibility reasons supporting SSL3 and TLS1 is preferable. You may get this with code: /* enable support of SSL2/SSL3/TLS1 */ ctx = SSL_CTX_new(SSLv23_server_method()); /* disable support of SSL2 */ SSL_CTX_set_options(ctx, SSL_OP_NO_SSLv2); In this case, even when SSL2 is disabled, ClientHello SSL2 handshake packet is understood and accepted if has hint for support higher protocols (SSL3/TLS1). Best regards, -- Marek Marcola [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: Wrapping SSL_read/SSL_write so they behave like read/write.]
Apologies if this is a duplicate; I was messing around with my e-mail
yesterday and it was broken for a while. I didn't see this go through.
On Sun, Aug 20, 2006 at 06:54:36PM -0400, Joe Flowers wrote:
It means call exactly the same SSL function you just did with the exact
same parameters as you just did that produced this SSL_ERROR_WANT_WRITE
return.
Pardon me, I think I'm a little thick today. I get what you're
all saying but I'm still not 100% sure of how this should be applied.
Here's the program flow, without SSL:
while(!quit) {
for(i in all file descriptors) {
if(we have something buffered up to say to the server)
FD_SET(thisfd, writefds)
/* we are always interested in what the server has to say
* to us */
FD_SET(thisfd, readfds);
}
select(maxfd + 1, readfds, writefds, NULL, timeout);
if(FD_ISSET(thisfd, readfds)) {
read(thisfd), process it, probably send a reply with write()
} else if(FD_ISSET(thisfd, writefds) {
write(thisfd) whatever we have buffered up; if it was a partial
write, update the buffer.
}
}
Using SSL, how should this look? From what I'm hearing, it shouldn't
use select() at all. So how do I find out if the server has something
to say short of polling it with SSL_read?
Thanks,
Steve.
- End forwarded message -
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager [EMAIL PROTECTED]
Re: Wrapping SSL_read/SSL_write so they behave like read/write.]
Hello,
Pardon me, I think I'm a little thick today. I get what you're
all saying but I'm still not 100% sure of how this should be applied.
Here's the program flow, without SSL:
while(!quit) {
for(i in all file descriptors) {
if(we have something buffered up to say to the server)
FD_SET(thisfd, writefds)
/* we are always interested in what the server has to say
* to us */
FD_SET(thisfd, readfds);
}
select(maxfd + 1, readfds, writefds, NULL, timeout);
if(FD_ISSET(thisfd, readfds)) {
read(thisfd), process it, probably send a reply with write()
} else if(FD_ISSET(thisfd, writefds) {
write(thisfd) whatever we have buffered up; if it was a partial
write, update the buffer.
}
}
Using SSL, how should this look? From what I'm hearing, it shouldn't
use select() at all. So how do I find out if the server has something
to say short of polling it with SSL_read?
You may use select() but with some care.
Simplest way is to:
1) wait on select()
2) read hit from SSL descriptor occur
3) read incrementally with SSL_read() from that descriptor until
WANT_READ
(or in other words - get all data from SSL read buffer)
4) go to select()
In 3) you may get WANT_WRITE too, in this case you should go to select()
and wait for write hit on SSL descriptor and perform 3) as you
do when you get read hit in select() on this SSL descriptor.
Best regards,
--
Marek Marcola [EMAIL PROTECTED]
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager [EMAIL PROTECTED]
Re: Hiding headers for OpenSSL
Guys, While I appreciate the vibrant discussion, I was not asking for the pros and cons of hiding the header information, whether or not one feels it promotes security, and whether one believes meddling with this makes one a geek or not. In many people's desire to announce their opinion on the matter, the question was ignored. Your thoughts are much appreciated, but I need a technical answer. My question is (rephrased), if possible, how can I hide the headers in OpenSSL from being broadcast to software running rudimentary security scans (e.g., Nessus)? Is there a line I can add to a conf file? Is preventing the broadcast of software, version, and OS through Apache all I need to do to prevent people from seeing that information? Last (though new) question: I thought that OpenSSL does not pass header information back and forth to the client when establishing a secure connection, but in fact, only certificate authenticating is performed? In other words, the client (however legitimate) doesn't need to know the header information of my OpenSSL; if the certificate is authenticated, the connection is made. Thanks in advance, Scott
license question
Originally I sent this letter to [EMAIL PROTECTED], as indicated by the license file, but I never got a response. Hopefully you in openssl-users can help. I work for nFocal, a company in Rochester, New York. We want to develop a variant of OpenSSL in which we optimize the cryptography library to run on a particular DSP. The other components of OpenSSL would remain unchanged except where needed to utilize our custom library. We might modify OpenSSL's cryptography library, or we may write our own from scratch. Could you please explain our licensing restrictions for these two scenarios? In particular, we are unclear as to what redistribution rights the OpenSSL license would grant to customers who purchase our OpenSSL variant. Would they be allowed to redistribute our optimized library? Your help is greatly appreciated. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: Wrapping SSL_read/SSL_write so they behave like read/write.]
Do something like this for a SSL_read() and something very similar for
SSL_write() and SSL_shutdown(), etc. (I'm assuming non-blocking sockets):
-
totalbytesread=0;
stop='n';
unsigned char buf[bufsize]=\0;
totaltime=0;
memset(buf, 0, bufsize);
do {
ret=select(maxfd + 1, readfds, writefds, exceptionfds, timeout);
if(select() fails, times out, or has exceptionfds) {
bail='y';
}
if((stop=='n')(bail=='n')) {
if(bufsize-1-totalbytesread 1) {
stop='y'; and/or bail='y'; depending on your situation; }
if((stop=='n')(bail=='n')) {
ret2=SSL_Read(buf[totalbytesread], bufsize-1-totalbytesread);
if(ret21) {
ret3=SSL_get_error(ret2);
if((ret3!=WANT_READ)(ret3!=WANT_WRITE)) {
bail='y';
} if((ret3!=WANT_READ)(ret3!=WANT_WRITE))
} //if(ret21)
else { //OK, we've read more bytes
oldtotalbytesread=totalbytesread;
totalbytesread=ret2+totalbytesread;
if((bufsize-1-totalbytesread)1) {
buf[oldtotalbytesread]='\0';
stop='y'; and/or bail='y'; depending on your situation;
} else {
buf[totalbytesread]='\0';
}
if((bail=='n')(stop=='n')) {
totaltime=totaltime+(this time here - last time here);
Check to see if buf contains information that tells you it's time to stop or
if too much time has been taken for this whole SSL_Read() routine.
if(time to stop) {
stop='y'; (and/or bail='y' for too much time) ; depending on your situation.
} //if(time to stop)
} //if((bail=='n')(stop=='n'))
} //else OK, we've read more bytes
} //if((stop=='n')(bail=='n'))
} //if((stop=='n')(bail=='n'))
} //while((stop=='n')(bail=='n'));
if(bail=='n'){
printf(\nbuf=(%s).\0, buf);
} else {
printf(\nFatal Error!\0);
}
-
Good luck!
Joe
Steven Young wrote:
Apologies if this is a duplicate; I was messing around with my e-mail
yesterday and it was broken for a while. I didn't see this go through.
On Sun, Aug 20, 2006 at 06:54:36PM -0400, Joe Flowers wrote:
It means call exactly the same SSL function you just did with the exact
same parameters as you just did that produced this SSL_ERROR_WANT_WRITE
return.
Pardon me, I think I'm a little thick today. I get what you're
all saying but I'm still not 100% sure of how this should be applied.
Here's the program flow, without SSL:
while(!quit) {
for(i in all file descriptors) {
if(we have something buffered up to say to the server)
FD_SET(thisfd, writefds)
/* we are always interested in what the server has to say
* to us */
FD_SET(thisfd, readfds);
}
select(maxfd + 1, readfds, writefds, NULL, timeout);
if(FD_ISSET(thisfd, readfds)) {
read(thisfd), process it, probably send a reply with write()
} else if(FD_ISSET(thisfd, writefds) {
write(thisfd) whatever we have buffered up; if it was a partial
write, update the buffer.
}
}
Using SSL, how should this look? From what I'm hearing, it shouldn't
use select() at all. So how do I find out if the server has something
to say short of polling it with SSL_read?
Thanks,
Steve.
- End forwarded message -
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager [EMAIL PROTECTED]
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager [EMAIL PROTECTED]
Re: Hiding headers for OpenSSL
Scott Campbell wrote: [...] My question is (rephrased), if possible, how can I hide the headers in OpenSSL from being broadcast to software running rudimentary security scans (e.g., Nessus)? Is there a line I can add to a conf file? Is preventing the broadcast of software, version, and OS through Apache all I need to do to prevent people from seeing that information? Last (though new) question: I thought that OpenSSL does not pass header information back and forth to the client when establishing a secure connection, but in fact, only certificate authenticating is performed? In other words, the client (however legitimate) doesn't need to know the header information of my OpenSSL; if the certificate is authenticated, the connection is made. Thanks in advance, Scott Looks like you missed Lutz' mail, since he (IMHO) answers your questions: This discussion is useless: * OpenSSL does not disclose its version to attackers coming from the network as the SSL/TLS protocol does not give any version information of the software used (it does give protocol compatibility information needed for interoperability wrt SSLv2, SSLv3 etc) * It is the application using OpenSSL (in this case Apache) disclosing the information. - Please complain to the Apache people. * Both projects OpenSSL and Apache are Open Source projects. If you find anything about it annoying please feel free to make any modification you want. I might add the following: There is a configuration option of Apache which allows you to customize the reported version string in the HTTP headers, but I just don't remember its name. If that is not flexible enough (and I remember it correctly) the responsible part of the Apache source code is not hard to find either. ;) Ted ;) -- PGP Public Key Information Download complete Key from http://www.convey.de/ted/tedkey_convey.asc Key fingerprint = 31B0 E029 BCF9 6605 DAC1 B2E1 0CC8 70F4 7AFB 8D26 smime.p7s Description: S/MIME Cryptographic Signature
Re: Hiding headers for OpenSSL
You are correct; I did miss Lutz's email.Lutz ... thank you. That is exactly the answer I was looking for, to all my questions.Thank you openssl list, and to all those who provided helpful feedback. Sincerely, ScottOn 8/22/06, Bernhard Froehlich [EMAIL PROTECTED] wrote: Scott Campbell wrote: [...] My question is (rephrased), if possible, how can I hide the headers in OpenSSL from being broadcast to software running rudimentary security scans (e.g., Nessus)? Is there a line I can add to a conf file? Is preventing the broadcast of software, version, and OS through Apache all I need to do to prevent people from seeing that information? Last (though new) question: I thought that OpenSSL does not pass header information back and forth to the client when establishing a secure connection, but in fact, only certificate authenticating is performed?In other words, the client (however legitimate) doesn't need to know the header information of my OpenSSL; if the certificate is authenticated, the connection is made. Thanks in advance, ScottLooks like you missed Lutz' mail, since he (IMHO) answers your questions: This discussion is useless: * OpenSSL does not disclose its version to attackers coming from the network as the SSL/TLS protocol does not give any version information of the software used (it does give protocol compatibility information needed for interoperability wrt SSLv2, SSLv3 etc) * It is the application using OpenSSL (in this case Apache) disclosing the information. - Please complain to the Apache people. * Both projects OpenSSL and Apache are Open Source projects. If you find anything about it annoying please feel free to make any modification you want.I might add the following: There is a configuration option of Apachewhich allows you to customize the reported version string in the HTTPheaders, but I just don't remember its name. If that is not flexible enough (and I remember it correctly) theresponsible part of the Apache source code is not hard to find either. ;)Ted;)--PGP Public Key InformationDownload complete Key from http://www.convey.de/ted/tedkey_convey.ascKey fingerprint = 31B0 E029 BCF9 6605 DAC1B2E1 0CC8 70F4 7AFB 8D26 -- Scott Campbell[EMAIL PROTECTED]Listen to the mustn'ts, child...
Re: license question
Ryan Shon wrote: In particular, we are unclear as to what redistribution rights the OpenSSL license would grant to customers who purchase our OpenSSL variant. Would they be allowed to redistribute our optimized library? The license enumerates the conditions which have to be met for redistribution. I think the discussion can be shortened when you explain which point of the license is unclear to you. Ciao, Richard -- Dr. Richard W. Könning Fujitsu Siemens Computers GmbH __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
RE: Hiding headers for OpenSSL
Title: Message Folks, For the sake of closure (and finality, one would hope :-) ), the relevant Apache configuration parameter is "ServerTokens". There is also a spiffy module available to do just about anything you might desire here: modsecurity. Works for me... rnd -Original Message-From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Scott CampbellSent: Tuesday, August 22, 2006 11:21 AMTo: openssl-users@openssl.orgSubject: Re: Hiding headers for OpenSSLYou are correct; I did miss Lutz's email.Lutz ... thank you. That is exactly the answer I was looking for, to all my questions.Thank you openssl list, and to all those who provided helpful feedback.Sincerely, Scott On 8/22/06, Bernhard Froehlich [EMAIL PROTECTED] wrote: Scott Campbell wrote: [...] My question is (rephrased), if possible, how can I hide the headers in OpenSSL from being broadcast to software running rudimentary security scans (e.g., Nessus)? Is there a line I can add to a conf file? Is preventing the broadcast of software, version, and OS through Apache all I need to do to prevent people from seeing that information? Last (though new) question: I thought that OpenSSL does not pass header information back and forth to the client when establishing a secure connection, but in fact, only certificate authenticating is performed?In other words, the client (however legitimate) doesn't need to know the header information of my OpenSSL; if the certificate is authenticated, the connection is made. Thanks in advance, ScottLooks like you missed Lutz' mail, since he (IMHO) answers your questions: This discussion is useless: * OpenSSL does not disclose its version to attackers coming from the network as the SSL/TLS protocol does not give any version information of the software used (it does give protocol compatibility information needed for interoperability wrt SSLv2, SSLv3 etc) * It is the application using OpenSSL (in this case Apache) disclosing the information. - Please complain to the Apache people. * Both projects OpenSSL and Apache are Open Source projects. If you find anything about it annoying please feel free to make any modification you want.I might add the following: There is a configuration option of Apachewhich allows you to customize the reported version string in the HTTPheaders, but I just don't remember its name. If that is not flexible enough (and I remember it correctly) theresponsible part of the Apache source code is not hard to find either. ;)Ted;)--PGP Public Key InformationDownload complete Key from http://www.convey.de/ted/tedkey_convey.ascKey fingerprint = 31B0 E029 BCF9 6605 DAC1B2E1 0CC8 70F4 7AFB 8D26-- Scott Campbell[EMAIL PROTECTED]"Listen to the mustn'ts, child..."
Re: Wrapping SSL_read/SSL_write so they behave like read/write.]
On Tue, Aug 22, 2006 at 03:00:46PM +0200, Marek Marcola wrote:
You may use select() but with some care.
Simplest way is to:
1) wait on select()
2) read hit from SSL descriptor occur
3) read incrementally with SSL_read() from that descriptor until
WANT_READ
(or in other words - get all data from SSL read buffer)
4) go to select()
So does the following not-really-pseudocode look right (connobjs is
a linked list of connection objects)?
for(cp = connobjs; cp; cp = cp-next)
cp-want_write = false;
while(!quit) {
for(cp = connobjs; cp; cp = cp-next) {
if(cp-want_write || cp-output_buffer) {
/* either openssl wants to say something, or
* we want to send something */
FD_SET(cp-fd, writefds);
} else {
FD_SET(cp-fd, readfds);
}
}
select(maxfd + 1, readfds, writefds, NULL, timeout);
for(cp = connobjs; cp; cp = cp-next) {
if(cp-want_write || cp-output_buffer) {
if(FD_ISSET(cp-fd, writefds) {
if(cp-output_buffer) {
byteswr = SSL_write(cp-sslobj,
cp-output_buffer,
cp-output_bufsz);
if(byteswr = 0) {
err = ERR_get_error(cp-sslobj);
if(err == SSL_ERROR_WANT_WRITE)
cp-want_write = true;
} else {
remove_bytes_from_beginning_of_buffer(cp-output_buffer,
cp-output_bufsz);
}
}
}
}
}
}
You'll note I ignore SSL_ERROR_WANT_READ, because I am always
interested in if the server has anything to say, so I will always have
every fd in the readfds set _except_ when the last SSL error was
SSL_ERROR_WANT_WRITE.
This sound like it's probably a very FAQ. Once this is sorted out
is there somewhere I should send it to for inclusion?
Thanks,
Steve.
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager [EMAIL PROTECTED]
Re: license question
Richard Koenning wrote: Ryan Shon wrote: In particular, we are unclear as to what redistribution rights the OpenSSL license would grant to customers who purchase our OpenSSL variant. Would they be allowed to redistribute our optimized library? The license enumerates the conditions which have to be met for redistribution. I think the discussion can be shortened when you explain which point of the license is unclear to you. Ciao, Richard My boss hopes to sell this OpenSSL variant as a product. Because of this, he would not want customers who buy this product to be free to redistribute it on their own. If we were only to modify existing OpenSSL, then I assume our entire product would be subject to free redistribution by customers under the license. Is this correct? However, if the cryptographic library in our OpenSSL variant were written from scratch, using no OpenSSL code (while the SSL library still used OpenSSL code), would we have the right to forbid redistribution of our cryptographic library and its source? I hope that clarifies my question. Again, thank you for your help. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: Wrapping SSL_read/SSL_write so they behave like read/write.]
On Tue, Aug 22, 2006 at 12:06:29PM -0400, Steven Young wrote:
On Tue, Aug 22, 2006 at 03:00:46PM +0200, Marek Marcola wrote:
You may use select() but with some care.
Simplest way is to:
1) wait on select()
2) read hit from SSL descriptor occur
3) read incrementally with SSL_read() from that descriptor until
WANT_READ
(or in other words - get all data from SSL read buffer)
4) go to select()
So does the following not-really-pseudocode look right (connobjs is
a linked list of connection objects)?
To answer my own question: No. Here is an amended version.
for(cp = connobjs; cp; cp = cp-next)
cp-want_write = false;
while(!quit) {
for(cp = connobjs; cp; cp = cp-next) {
if(cp-want_write || cp-output_buffer) {
/* either openssl wants to say something, or
* we want to send something */
FD_SET(cp-fd, writefds);
} else {
FD_SET(cp-fd, readfds);
}
}
select(maxfd + 1, readfds, writefds, NULL, timeout);
for(cp = connobjs; cp; cp = cp-next) {
if(cp-want_write || cp-output_buffer) {
if(FD_ISSET(cp-fd, writefds) {
if(cp-output_buffer) {
byteswr = SSL_write(cp-sslobj,
cp-output_buffer,
cp-output_bufsz);
if(byteswr = 0) {
err = ERR_get_error(cp-sslobj);
if(err == SSL_ERROR_WANT_WRITE)
cp-want_write = true;
} else {
remove_bytes_from_beginning_of_buffer(cp-output_buffer,
cp-output_bufsz);
}
} else {
bytesrd = SSL_read(cp-sslobj,
cp-input_buffer,
cp-input_bufsz);
if(bytesrd = 0) {
err = ERR_get_error(cp-sslobj);
if(err == SSL_ERROR_WANT_WRITE)
cp-want_write = true;
} else {
do_something_with_buffer(cp);
}
}
} else if(FD_ISSET(cp-fd, readfds)) {
bytesrd = SSL_read(cp-sslobj,
cp-input_buffer,
cp-input_bufsz);
if(bytesrd = 0) {
err = ERR_get_error(cp-sslobj);
if(err == SSL_ERROR_WANT_WRITE)
cp-want_write = true;
} else {
do_something_with_buffer(cp);
}
}
}
}
}
There's plenty of redundant code up there but I thought it would be
more clear than factoring stuff out.
Steve.
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager [EMAIL PROTECTED]
Re: license question
Ryan Shon wrote: My boss hopes to sell this OpenSSL variant as a product. Because of this, he would not want customers who buy this product to be free to redistribute it on their own. If we were only to modify existing OpenSSL, then I assume our entire product would be subject to free redistribution by customers under the license. Is this correct? My first answer would have been plain no, but then i read the last sentences at http://www.openssl.org/source/license.html. I think (IANAL) that the answer depends on whether your product is regarded a derivative of OpenSSL. If you can put the main part of your code into a separate module and only modify OpenSSL to call your code then i assume that you can forbid the redistribution of *your* module. Whether you are allowed to forbid the redistribution of the modified OpenSSL may be questionable, but without your module this OpenSSL version is useless anyway. However, if the cryptographic library in our OpenSSL variant were written from scratch, using no OpenSSL code (while the SSL library still used OpenSSL code), would we have the right to forbid redistribution of our cryptographic library and its source? Yes (but you know, IANAL ;-)). Ciao, Richard -- Dr. Richard W. Könning Fujitsu Siemens Computers GmbH __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: license question
In message [EMAIL PROTECTED] on Tue, 22 Aug 2006 18:47:12 +0200, Richard Koenning [EMAIL PROTECTED] said: Richard.Koenning Ryan Shon wrote: Richard.Koenning Richard.Koenning My boss hopes to sell this OpenSSL variant as a Richard.Koenning product. Because of this, he would not want Richard.Koenning customers who buy this product to be free to Richard.Koenning redistribute it on their own. If we were only to Richard.Koenning modify existing OpenSSL, then I assume our entire Richard.Koenning product would be subject to free redistribution by Richard.Koenning customers under the license. Is this correct? Richard.Koenning Richard.Koenning My first answer would have been plain no, but then Richard.Koenning i read the last sentences at Richard.Koenning http://www.openssl.org/source/license.html. I think Richard.Koenning (IANAL) that the answer depends on whether your Richard.Koenning product is regarded a derivative of OpenSSL. For all intents and purposes, yes, it would, at least if the modification is distributed in a package that otherwise looks like a full OpenSSL distribution. IANAL either, but I think I've read enough to be able to make that statement with certainty. Cheers, Richard - Please consider sponsoring my work on free software. See http://www.free.lp.se/sponsoring.html for details. -- Richard Levitte [EMAIL PROTECTED] http://richard.levitte.org/ When I became a man I put away childish things, including the fear of childishness and the desire to be very grown up. -- C.S. Lewis __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: Wrapping SSL_read/SSL_write so they behave like read/write.]
Original message Date: Tue, 22 Aug 2006 15:00:46 +0200 From: Marek Marcola [EMAIL PROTECTED] Subject: Re: Wrapping SSL_read/SSL_write so they behave like read/write.] To: openssl-users@openssl.org You may use select() but with some care. Simplest way is to: 1) wait on select() 2) read hit from SSL descriptor occur 3) read incrementally with SSL_read() from that descriptor until WANT_READ (or in other words - get all data from SSL read buffer) 4) go to select() In 3) you may get WANT_WRITE too, in this case you should go to select() and wait for write hit on SSL descriptor and perform 3) as you do when you get read hit in select() on this SSL descriptor. Are you suggesting that the write hit from select is an indication that the descriptor is writable and hence the data that SSL required to write before it could serve our read request must have been written. And so we would expect a successful SSL_read after this write hit from select? Moreover, should we not wait again for a read hit from select before we SSL_read()? Best regards, -- Marek Marcola [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager [EMAIL PROTECTED] DISCLAIMER == This e-mail may contain privileged and confidential information which is the property of Persistent Systems Pvt. Ltd. It is intended only for the use of the individual or entity to which it is addressed. If you are not the intended recipient, you are not authorized to read, retain, copy, print, distribute or use this message. If you have received this communication in error, please notify the sender and delete all copies of this message. Persistent Systems Pvt. Ltd. does not accept any liability for virus infected mails. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: Wrapping SSL_read/SSL_write so they behave like read/write.]
Hello, You may use select() but with some care. Simplest way is to: 1) wait on select() 2) read hit from SSL descriptor occur 3) read incrementally with SSL_read() from that descriptor until WANT_READ (or in other words - get all data from SSL read buffer) 4) go to select() In 3) you may get WANT_WRITE too, in this case you should go to select() and wait for write hit on SSL descriptor and perform 3) as you do when you get read hit in select() on this SSL descriptor. Are you suggesting that the write hit from select is an indication that the descriptor is writable and hence the data that SSL required to write before it could serve our read request must have been written. Yes. And so we would expect a successful SSL_read after this write hit from select? Depends what successful means. If, from last SSL_read() we have got WANT_WRITE then this means that before reading application data some SSL protocol data must be written (renegotiation packet, non critical alert packet, ...). This requires writable socket, so we waiting when socket is writable ... and from select() we get such hint ... so we call SSL_read() again ... now SSL layer write some protocol data to peer ... maybe read some protocol data from peer ... lets assume that this ends successfully ... now SSL tries to read some application data ... if in TCP buffers is SSL application record ready to decrypt ... (which means full record) ... this record is decrypted ... and some data is returned to SSL_read() caller ... if there is no SSL record ready ... WANT_READ is returned to SSL_read() caller... and caller may call select(). Some explanation of some data is returned to SSL_read() caller: Assume that SSL application record after decryption has 200 bytes. If SSL_read() wants to get 110 bytes then 90 bytes will wait in SSL read buffer. This call to SSL_read() will return 110 (number of bytes read from SSL buffer). If we now go to select() then we may have deadlock because our peer send us 200 bytes, we have still 90 to read but instead of reading this bytes we waiting in select(). To resolve this problem we can call SSL_pending() before select() to check if SSL buffers are empty or not, or call SSL_read() until WANT_READ is returned. For example (some pseudo-code :-): - first SSL_read(s, buf, 110) = 110 - second SSL_read(s, buf+110, 110) = 90 - third SSL_read(s, buf+200, 110) = -1 + WANT_READ and SSL bufers are empty, we have 200 bytes of data and we can go to select(). Of course this is for non-blocking sockets. Best regards, -- Marek Marcola [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
related license question
Thank you for the clarification. What you have said makes sense, but I am still a little unclear on what is meant by redistribution and products derived from [OpenSSL]. Presumably, a program, e.g. a web browser, could be written which uses OpenSSL (whether through linking to the libraries or by including actual pieces of OpenSSL code), and this browser would not have to be licensed under the OpenSSL license. This would be a product derived from OpenSSL, and users could be forbidden to redistribute the browser in source or binary forms. Is this a correct interpretation of what a product derived is? If a person were to take a full OpenSSL distribution and completely rewrite some source files, but not all source files, of which libcrypto.a is composed, then compile and distribute the resulting libraries libssl.a and libcrypto.a, would libssl.a be a redistribution, and would libcrypto.a be a product derived or a redistribution? In other words, would the person be able to prohibit redistribution of their new libcrypto.a, even though it utilizes some unmodified OpenSSL code, and is part of a complete OpenSSL distribution? I appreciate your help. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: related license question
In message [EMAIL PROTECTED] on Tue, 22 Aug 2006 15:07:31 -0400, Ryan Shon [EMAIL PROTECTED] said: rshon Presumably, a program, e.g. a web browser, could be written rshon which uses OpenSSL (whether through linking to the libraries or rshon by including actual pieces of OpenSSL code), and this browser rshon would not have to be licensed under the OpenSSL license. This rshon would be a product derived from OpenSSL, and users could be rshon forbidden to redistribute the browser in source or binary forms. rshon Is this a correct interpretation of what a product derived rshon is? I'm actually unsure about that. Richard Stallman would probably interpret it that way, but I wouldn't. Using unmodified components from another package in your own package does not constitute derivation, in my opinion. But again, IANAL. rshon If a person were to take a full OpenSSL distribution and rshon completely rewrite some source files, but not all source files, rshon of which libcrypto.a is composed, then compile and distribute rshon the resulting libraries libssl.a and libcrypto.a, would rshon libssl.a be a redistribution, and would libcrypto.a be a rshon product derived or a redistribution? If we look at the separate libraries, then yes. However, I would assume that you would distribute this changed source in the same manner as the original is distributed, in one package. In that case, that package is a modified version of OpenSSL, and therefore a product derived from OpenSSL. Cheers, Richard - Please consider sponsoring my work on free software. See http://www.free.lp.se/sponsoring.html for details. -- Richard Levitte [EMAIL PROTECTED] http://richard.levitte.org/ When I became a man I put away childish things, including the fear of childishness and the desire to be very grown up. -- C.S. Lewis __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
RE: Wrapping SSL_read/SSL_write so they behave like read/write.]
To answer my own question: No. Here is an amended version.
While I believe your code is okay, it can be improved in a few ways. It
contains some assumptions that are not always true, and it will work better
without those assumptions.
for(cp = connobjs; cp; cp = cp-next)
cp-want_write = false;
while(!quit) {
for(cp = connobjs; cp; cp = cp-next) {
if(cp-want_write || cp-output_buffer) {
Here your code contains the assumption that because you want to write
encrypted data to OpenSSL, SSL will need to write to the socket. It probably
will, but that's just as assumption. The test for cp-output_buffer should
not be there.
/* either openssl wants to say something, or
* we want to send something */
FD_SET(cp-fd, writefds);
} else {
FD_SET(cp-fd, readfds);
}
}
select(maxfd + 1, readfds, writefds, NULL, timeout);
for(cp = connobjs; cp; cp = cp-next) {
if(cp-want_write || cp-output_buffer) {
if(FD_ISSET(cp-fd, writefds) {
if(cp-output_buffer) {
byteswr = SSL_write(cp-sslobj,
cp-output_buffer,
cp-output_bufsz);
if(byteswr = 0) {
err = ERR_get_error(cp-sslobj);
if(err == SSL_ERROR_WANT_WRITE)
cp-want_write = true;
} else {
remove_bytes_from_beginning_of_buffer(cp-output_buffer,
cp-output_bufsz);
}
} else {
You don't call SSL_read if the socket is writable. That doesn't make any
sense.
bytesrd = SSL_read(cp-sslobj,
cp-input_buffer,
cp-input_bufsz);
if(bytesrd = 0) {
err = ERR_get_error(cp-sslobj);
if(err == SSL_ERROR_WANT_WRITE)
cp-want_write = true;
} else {
do_something_with_buffer(cp);
}
}
} else if(FD_ISSET(cp-fd, readfds)) {
bytesrd = SSL_read(cp-sslobj,
cp-input_buffer,
cp-input_bufsz);
if(bytesrd = 0) {
err = ERR_get_error(cp-sslobj);
if(err == SSL_ERROR_WANT_WRITE)
cp-want_write = true;
} else {
do_something_with_buffer(cp);
}
}
}
}
}
You should 'select' for writability if and only if you get a WANT_WRITE
indication, whether it comes from SSL_read or SSL_write. This is the *only*
thing that means that you would block while trying to send encrypted data to
the socket. (Whether or not you are trying to currently send any unencrypted
data has nothing to do with it.)
If you get a 'select' hit, whether for readability or writability, you
should retry *all* operations, whether reads or writes. (Obviously, don't
call SSL_write unless you have some data to write!)
Your code assumes that there is some correlation between the motion of
encrypted data and the motion of decrypted data. While, of course, there is,
your code should pretend there is not and let the SSL engine figure that
out.
Where do you clear 'want_write'?
Again, I also recommend trying an SSL_read on any hit, whether for
readability or writability, before doing anything else. This will 100%
ensure you don't deadlock (as long as you call SSL_read after each SSL_write
until it runs out) nd it will give you better behavior under edge conditions
like memory pressure.
Are you suggesting that the write hit from select is an
indication that the descriptor is writable and hence the data
that SSL required to write before it could serve our read
request must have been written. And so we would expect a
successful SSL_read after this write hit from select?
If you got a WANT_WRITE, that means the operation could not proceed
until
encrypted data could be written. Once the socket is writable, the operation
can proceed. So you should retry it. No harm in retrying all current
operations (always SSL_read, but SSL_write if there's unencrypted data to
send).
Moreover, should we not wait again for a read hit from select
before we SSL_read()?
That would be a disaster. The corresponding encrypted data might
RE: related license question
Thank you for the clarification. What you have said makes sense, but I am still a little unclear on what is meant by redistribution and products derived from [OpenSSL]. The term redistribution means any distribution of OpenSSL or a derivative work of OpenSSL other than what you might have a right to do by law (say under first sale or fair use). The term products derived from OpenSSL means any work that would be considered a derivative work under copyright law. Note that calling something 'OpenSSL' might also be a considered fraud or violations of common law trademarks and the like. I'm talking only about copyright. Presumably, a program, e.g. a web browser, could be written which uses OpenSSL (whether through linking to the libraries or by including actual pieces of OpenSSL code), and this browser would not have to be licensed under the OpenSSL license. This would be a product derived from OpenSSL, and users could be forbidden to redistribute the browser in source or binary forms. Is this a correct interpretation of what a product derived is? If it included actual pieces of OpenSSL code, other than that permitted under exceptions to copyright laws (fair use, scenes a faire), then those who distribute it must comply with the OpenSSL license when they do so. That does not mean their product has to be licensed under a license identical to the OpenSSL license. Note that they cannot authorize distributions of their derivative under terms not permitted by the OpenSSL license unless their creation of the derivative works was pursuant to rights no acquired under the OpenSSL license. (That gets complicated. If you want a more detailed explanation, email me.) Basically, you cannot wrap OpenSSL and claim that by using that wrapped OpenSSL instead of OpenSSL itself, you only need to comply with the wrapper's license. This is not because OpenSSL's authors have the right to restrict the distribution of derivative works, this is because this is a condition of creating the derivative work in the first place. If a person were to take a full OpenSSL distribution and completely rewrite some source files, but not all source files, of which libcrypto.a is composed, then compile and distribute the resulting libraries libssl.a and libcrypto.a, would libssl.a be a redistribution, Yes. and would libcrypto.a be a product derived or a redistribution? It would either be OpenSSL itself (if insufficient creative effort were involved in the process of creating this file) or it would be a product derived (if sufficient creative effort were added to consider it a distinct work). In other words, would the person be able to prohibit redistribution of their new libcrypto.a, even though it utilizes some unmodified OpenSSL code, and is part of a complete OpenSSL distribution? Certainly. Nothing in the OpenSSL licenses requires you to allow redistribution of any derivative works you create. (And anyone who did so would be violating *your* rights, not those of OpenSSL or its authors since copyright law doesn't permit you to restrict distribution of derivative works, only creation.) However, if the thing you distributed was legally deemed to be OpenSSL itself, rather than a derivative work, you could not prohibit redistribution (under copyright law). You do not hold copyright to OpenSSL itself, so nobody can violate any of your rights by distributing it. (Merely compiling OpenSSL, for example, doesn't give you any copyright rights in the results. You must add creative effort to acquire copyright interest.) You could try to prohibit such things with contracts and the like. IANAL. My responses exlclusively assume United States law, other countries do definitely differ. Consult a lawyer if any of this matters to you. HTH. DS __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
RE: Wrapping SSL_read/SSL_write so they behave like read/write.]
Original message
Date: Tue, 22 Aug 2006 12:22:37 -0700
From: David Schwartz [EMAIL PROTECTED]
Subject: RE: Wrapping SSL_read/SSL_write so they behave like
read/write.]
To: openssl-users@openssl.org
You should 'select' for writability if and only if you get a
WANT_WRITE
indication, whether it comes from SSL_read or SSL_write. This
is the *only*
thing that means that you would block while trying to send
encrypted data to
the socket. (Whether or not you are trying to currently send
any unencrypted
data has nothing to do with it.)
If you get a 'select' hit, whether for readability or
writability, you
should retry *all* operations, whether reads or writes.
(Obviously, don't
call SSL_write unless you have some data to write!)
Again, I also recommend trying an SSL_read on any hit,
whether for
readability or writability, before doing anything else. This
will 100%
ensure you don't deadlock (as long as you call SSL_read after
each SSL_write
until it runs out) nd it will give you better behavior under
edge conditions
like memory pressure.
Sorry, but could you give a little more explaination for this,
probably with an example?
Are you suggesting that the write hit from select is an
indication that the descriptor is writable and hence the data
that SSL required to write before it could serve our read
request must have been written. And so we would expect a
successful SSL_read after this write hit from select?
If you got a WANT_WRITE, that means the operation could not
proceed until
encrypted data could be written. Once the socket is writable,
the operation
can proceed. So you should retry it. No harm in retrying all
current
operations (always SSL_read, but SSL_write if there's
unencrypted data to
send).
Moreover, should we not wait again for a read hit from select
before we SSL_read()?
That would be a disaster. The corresponding encrypted data
might have
already been read. You should *never* assume no inbound data
will be
available until the socket is readable unless SSL_read just
returned
WANT_READ and you have no called SSL_write since then.
The SSL engine may have already read the encrypted data,
during a previous
call to SSL_read or a previous call to SSL_write! So waiting
for more data
to be received can deadlock you.
Do not assume that no unencrypted data can be read until
encrypted data can
be read unless you know this for a fact. The only way you can
know this for
a fact is if two things are the case:
1) Your last SSL_read returned WANT_READ, *and*
2) You have not called SSL_write since then.
Otherwise, you should *not* wait for readability before
calling SSL_read.
The encrypted data may have already been read.
Note that if an SSL_write returns WANT_READ, you should
'select' for
readability and then retry the SSL_write. No harm in doing an
SSL_read
before or after that. In fact, there are good reasons for
doing one both
before and after, assuming the first SSL_read doesn't return
'WANT_READ'.
So in short,
1) you check for socket readability if you get WANT_READ for
your last operation, and on hit you retry the last operation
(whether SSL_read or SSL_write).
2) You check for socket writability if you get WANT_WRITE for
the last operation, and on hit you retry that operation.
Is this understanding correct?
With this understanding, the following piece of code should
work with an assumption that you beforehand know how much of
application data are you expecting and set the buffer size
appropriately. Buffer full is one condition when you return
select(for the socket readability)
socket_ssl_read(fd) /* This is the wrapper */
process_the_data();
socket_ssl_read(fd)
{
set appropriate buffer size;
while(1)
{
ret = SSL_read();
if (ret 1)
{
ret1 = SSL_get_error();
switch(ret1)
{
case WANT_READ: select(for readability);
break;
case WANT_WRITE: select(for writability);
break;
default: return error;
}
}
if (buffer full)
return;
}
}
Something similar can be done for SSL_write wrapper.
In the current context, these wrappers can be called for each
connectio descriptor.
But then the wrappers will return only on error or after they
read the full data. So will that actually exibit blocking
behavior?
~ Urjit
DISCLAIMER
==
This e-mail may contain privileged and confidential information which is the
property of Persistent Systems Pvt. Ltd. It is intended only for the use of the
individual or entity to which it is addressed. If you are not the intended
recipient, you are not authorized to read, retain, copy, print, distribute or
use this message. If you have received this communication in error, please
notify the sender and delete all copies of this message. Persistent Systems
Pvt. Ltd. does not
