Rajeswari K wrote:
In our application we open non blocking socket for read and write
operation and pass the fd to openssl through BOI API's like this
bio = BIO_new(BIO_s_socket());
BIO_set_fd(bio, socket_fd, BIO_NOCLOSE);
And
we update this bio to SSL using SSL_set_bio() function.
My query
Rahila Syed wrote:
I am using OpenSSH compression for compressing data between
PostgreSQL servers. I am using following command,
ssh -c arcfour,blowfish-cbc -4 -2 -v -C -L 3304:localhost:5432 user@server2
I want to know if vulnerability CRIME which attacks SSL deflate
compression
Salz, Rich wrote:
The common practice is for clients to connect in the clear, then issue a command to turn
on TLS, such as the SMTP STARTTLS command.
It is only common practice for a small number of well known protocols.
This doesn't mean it is the best solution.
If you have a bespoke
Dave Mitchell wrote:
Can calls to non-blocking SSL_read() and SSL_write() be interleaved?
I'm doing select() / event driven IO, and using a BIO pair to handle the
underlying socket IO myself.
Yes, but not from 2 threads working on the same SSL * at the same time.
So your single threaded
YUN GAO wrote:
Hi there:
SSL_shutdown used to have a problem that in some instances it always
returns 0 no matter how many time it is called before 0.9.8l.
To solve the issue, I have to call SSL_shutdown() twice and check the
error number and return code at the second time: if the return code
is
Priyaranjan Nayak wrote:
I am using openssl-1.0.1c in our project.when SSL_shutdown(ssl)
get executed it returns 0.If I get return value zero then calling the
same SSL_shutdown(ssl) again.In 2nd time it return -1. Can any one tell
me how to shutdown ssl context ? How can I execute
Jakob Bohm wrote:
On 04-10-2010 21:10, Victor Duchovni wrote:
On Mon, Oct 04, 2010 at 10:37:55AM -0400, Jeff Saremi wrote:
Does BIO support 64 bit IO (large files)? If so would the rest of
OpenSSL (such as the ssl itself) support those BIOs?
I configured the build with 64bit support and
Jakob Bohm wrote:
I believe this is an unfortunate reading of the RFCs. Fundamentally,
the SSL3/TLS protocols do not tie the availability of a cipher suite to
the version of the protocol document which was current when it was
introduced. The fact that the most common cipher suites are defined in
Amit Ben Shahar wrote:
The documentation specifies that SSL_ERROR_ZERO_RETURN is returned if
the transport layer is closed normally.
My question is, how should i handle this return code?
specifically should i call SSL_free normally to free resources, or are
resources already freed?
Yes you
Amit Ben Shahar wrote:
Does anyone know if a buffer passed to ssl_write (or any other method)
must remain valid (i.e not freed) for any period.
for example, if i have this code:
// allocate buffer
char* tmpBuff = (char*)malloc(1024);
// .. some code to put data in buff
// write
Dr. Stephen Henson wrote:
Using the low level APIs had been strongly discouraged for some time.
This is an unfortunate choice.
OpenSSL used to have very usable digest and encryption lowlevel
routines. Such that an application could pick and choose to make use of
just a few routines.
I
I think the FAQ point is trying to highlight that the GZIP format as-is
was designed for single file compression (a compress replacement). So
therefore the extra tiny header at the start of the GZIP data that you
find in *.gz files is not necessary for zlib and streaming compressors.
Also
I thought they were the same thing ? Checkout http://www.zlib.net/
notice the Authors credited and the authors of Gzip http://www.gzip.org/
and deflate methods.
Alternatively you can use the BIO implementation for doing compression
as a template to write your own compression by bolting in
Matthew Allen wrote:
if (Ssl)
{
SSL_shutdown(Ssl);
SSL_free(Ssl);
}
Yes as the other writer says, you may need to close out the BIO (which
is the thing holding the socket descriptor/handle). So the Bio object
you created you may need to clean
Antoine Pitrou wrote:
Well, in our case, and unless I'm mistaken,
ret == -1, ERR_get_error() == 0 and then errno (the Unix errno) == 0.
SSL_shutdown() by virtue of its unique mechanic you will not see ret ==
0 (in the way the SSL_get_error man page describes) since that has a
different and
Antoine Pitrou wrote:
What I'm specifically interested in is SSL_ERROR_SYSCALL with errno==0.
I have investigated this issue of -1/SSL_ERROR_SYSCALL with errno==0.
From the SSL_get_error(3) man page:
SSL_ERROR_SYSCALL
Some I/O error occurred. The OpenSSL error queue may contain more
Antoine Pitrou wrote:
These issues are tracked together at http://bugs.python.org/issue8108 ,
because they both appeared when someone tried OpenSSL 0.9.8m.
I have read through the discussion first I'd like to confirm the
scenario for the errno==0 situation through particular sequence of
Would you please confirm to the list the name of the Python module, the
download site for it and the version you are currently working with.
This just helps up provide assistance to this same question in future.
Please read up on this recent thread. I do not know anything about
Python
Long info because I fear the Python module maybe misunderstanding what
SSL_shutdown() actually does and why it exists. Which in turn mean that
users of the Python module also misuse it (sandcastles in the sand and
all that).
Antoine Pitrou wrote:
While testing Python's SSL support with
Claus Assmann wrote:
It should probably be
ssl_errno = SSL_get_error(ssl, rc);
Ah yes you could be correct on that, please consult the SSL_get_error()
documentation for correct usage.
but even then I get SSL_ERROR_SYSCALL and errno=EBADF using sendmail
8, while previously it
Victor Stinner wrote:
I'm trying to fix a bug in Python which is specific to OpenSSL 0.9.8m. The
problem is in a FTP test using a blocking socket (client) and a non blocking
socket (server). There are different tests, some tests use a timeout of 2
seconds on the client socket.
Pseudo-code of
Please provide a simple testcase program exhibiting the memory leak.
Please try with the most recent OpenSSL release. There are no known
issue with normal usage, however some recent patches have been added for
theoretical failure path memory leaks.
It is possible for memory leaks to still
Mark wrote:
There is one added complication in that the protocol is a datagram
protocol at a
higher level (although it uses TCP). I am concerned that the whole
protocol could
block if there is not enough data to encrypt a whole outgoing message
but the peer cannot
continue until it gets the
Ger Hobbelt wrote:
It is presumed that every SSL_write() requires a flush (at TCP level this
mechanism is called a Push). This basically means the data needs to flush
to the reading API at the far end on exactly the byte boundary (or more)
data than you sent. This mean you have a guarantee to
Parimal Das wrote:
Its the second case Darry,
Here the 'sleep' is Operating System Sleep mode induced by closing the
lid of laptop.
After opening the laptop, when the system wakes up,
My application is always hanging at the same place.
It is possible there is something specific OSX does in
after wakeup from sleep ? What do you mean ?
Do you mean you used an API like poll() or select() to put the thread to
sleep and then it wakes up and the socket readability was indicated ?
If so please post an outline of the code your sleep/wake mechanism you
are using.
Do you mean your
David Schwartz wrote:
Darryl Miles wrote:
I do not believe the SSL_write() call is allowed to access the
underlying BIO/kernel-socket to read in more data. I think SSL_write()
is allowed to process any data already read into buffer (from kernel to
OpenSSL library internal buffer
Kyle Hamilton wrote:
My understanding is that if SSL_ERROR_WANT_WRITE happened with
SSL_read(), the next SSL_read() would actually call write() to make
the forward progress.
Yes that is possible, as the data for the write is already inside
OpenSSL library. Infact all the write to BIO/kernel
Konstantin Ivanov wrote:
I am developing a server application which is based on Windows IO
Completion ports which basically means that the reads and write to the
socket are asynchronous. This also means that I cannot use the SSL_read
and SSL_write functions which are tied to the socket fd if
Victor Duchovni wrote:
SSL is a state-machine, not a pipe. Reading data may require writes, and
writing data may require reads (e.g. when re-negotiating). If you want
to write and read as data arrives in either direction, don't block, and
enter the state machine to move data in either direction
The issue is down to the OpenSSL API thread-safety rules (which are
dictated to by the internal design of OpenSSL).
I covered those thread-safety rules in a previous posting.
Yes the common application design pattern for full-duplex SSL streams is
to only ever have one thread doing the
David Schwartz wrote:
Darryl Miles wrote:
But this flag (while documented to the contrary) does nothing inside
libssl. So yes the documentation says you should set it, prove to me
that OpenSSL behaves in a different way because you set it.
One of the biggest downsides of open source
David Schwartz wrote:
Darryl Miles wrote:
This is how everything else works, it's odd to say it's somehow a limitation
of OpenSSL that it works the same way everything else works. Try to read to
a string in one thread while you write to it from another. The general rule
of thread
David Schwartz wrote:
Jason Pettiss wrote:
I have a server which reads/writes a socket independently; that is to
say, at the same time (not a request-response model). I note in the
FAQ it says I must not allow multiple threads to use an SSL connection,
so clearly if my sockets are blocking I
Andrew Sumner wrote:
The client can then send messages to the server worker process using
SSL_write, and the worker receives them ok. However, when the worker
sends something to the client, nothing comes through - SSL_read fails.
In summary, is there any way of closing an SSL session on a
Kyle Hamilton wrote:
If SSL_ERROR_WANT_READ or SSL_ERROR_WANT_WRITE are returned, the
arguments *must* be *exactly* the same. This includes the data
pointed to by the buffer. There is a way to set a mode on the SSL
connection to allow a moving buffer, but that's it. SSL will not
buffer the
Steve West wrote:
I now get the message unsupported methods from bio_read. I get this
message from my server when I try to connect using openssl s_client. Any
suggestions?
Steve
Have you added options like -msg and -debug to your s_client invocation ?
Did you then post your data to the
Steve West wrote:
I get the message unsupported methods from ssl_accept() bio_read. I
get this message from my server when I try to connect using openssl
s_client. Any suggestions?
Steve
It is possible to implement STARTTLS with OpenSSL.
This is where you connect your
==13777== 128 bytes in 1 blocks are still reachable in loss record 1 of 2
==13777==at 0x4004BEC: realloc (vg_replace_malloc.c:306)
==13777==by 0x8052515: default_realloc_ex (mem.c:86)
==13777==by 0x8052B3E: CRYPTO_realloc (mem.c:331)
==13777==by 0x8062B64: contract (lhash.c:369)
Stanislav Mikhailenko wrote:
CRYPTO_mem_ctrl(CRYPTO_MEM_CHECK_ON);
SSLeay_add_ssl_algorithms();
SSL_load_error_strings();
ERR_remove_state(0);
ERR_free_strings();
EVP_cleanup();
CRYPTO_cleanup_all_ex_data();
ENGINE_cleanup();
CONF_modules_unload(1);
This code
David Schwartz wrote:
Which is pretty much the same as every other operation. If you call 'send'
or 'write' on a blocking TCP socket, and you get a zero return, does that
mean the data has been sent? No. It means the data is queued and the send is
in progress. If you call 'shutdown' on a
[EMAIL PROTECTED] wrote:
I have an application which is occasionally hanging. I have tracked it
down to an SSL_shutdown call.
There is an issue with SSL_shutdown() on non-blocking sockets in respect
of knowing when to use the shutdown() call.
I'm not exactly sure if you have run into this
Mark wrote:
Presumably you can use multiple threads for reading and writing as long
as you
ensure that they are not both calling an SSL function at the same time?
Function ???
The important aspect is the principal object/handle you are passing the
function. For most of the API that an
Jinsong Du wrote:
I have a simple server using blocked socket and OpenSSL, its only
function is for user registering an account. When an user connect to
this server, it spawns a child process to handle the request. I found
sometime child processes got stuck.
The problem here is that what if 2
Bobby Krupczak wrote:
1) In bn_rand.c add at line 141: memset(buf, 0, bytes); =20
buf = (unsigned char *)OPENSSL_malloc(bytes);
if (buf == NULL)
{
BNerr(BN_F_BNRAND,ERR_R_MALLOC_FAILURE);
goto err;
}
memset(buf, 0, bytes);
2) bn_mont.c: Initialize
Dr. Stephen Henson wrote:
Our goal is really to save and restore the cipher state of an RC4 cipher
context. It does not seem to be possible to ask an EVP_CIPHER_CTX to save
and restore it's internal state. Any ideas would be welcomed?
Here here! I feel your pain. Search the
Maybe they can, but you wont get much response from me by being too lazy
to start a new thread with your Compose New Mail function, as opposed
to picking a historic message at random and using the Reply To Message
function.
Have a nice day!
The Posting Police
Paul Simon wrote:
I have a
Florian Schnabel wrote:
i tried both the etch version and the stock version of openssl 0.9.8e
and got exactly the same error
comment out your FD_ZERO(), FD_SET() and FD_ISSET() macros from the file
s_server.c this will confirm the problem is with glibc, then please file
a bug report with
Darryl Miles wrote:
Florian Schnabel wrote:
spider:/opt/openssl-0.9.8e-etch/apps# gcc -DMONOLITH -I.. -I../include
-DOPENSSL_THREADS -D_REENTRANT \
-DDSO_DLFCN -DHAVE_DLFCN_H -m64 -DL_ENDIAN -DTERMIO -O3 -Wall \
-DMD32_REG_T=int -DMD5_ASM -c -o s_server.o s_server.s
s_server.s
Florian Schnabel wrote:
spider:/opt/openssl-0.9.8e-etch/apps# gcc -DMONOLITH -I.. -I../include
-DOPENSSL_THREADS -D_REENTRANT \
-DDSO_DLFCN -DHAVE_DLFCN_H -m64 -DL_ENDIAN -DTERMIO -O3 -Wall \
-DMD32_REG_T=int -DMD5_ASM -c -o s_server.o s_server.s
s_server.s: Assembler messages:
Please take a look at this thread for assistance.
http://www.mail-archive.com/[EMAIL PROTECTED]/msg22972.html
In your case manually run these 3 commands:
cd apps
gcc -DMONOLITH -I.. -I../include -DOPENSSL_THREADS -D_REENTRANT \
-DDSO_DLFCN -DHAVE_DLFCN_H -m64 -DL_ENDIAN -DTERMIO -O3 -Wall
Steffen DETTMER wrote:
this is an interesting topic. I hope it is OK to bother again
even if off-topic.
This topic has been covered before on this list. I do not share David's
beliefs on this matter, the select() readability and writability
indicators are indeed sticky.
That is they never
David Schwartz wrote:
That is not only not implemented by any known implementation but quite
literally impossible. Please tell me what implementation guarantees that a
TCP 'write' after a 'select' hit for writability will not block.
This is no use, your asking me for references and I'm asking
Prabhu S wrote:
Is this a memory leak. If I run the client application under stress, I
run into issues with available swap size reducing to zero( free -m
command) ..I have resolved significant application memory leak. Still I
run into problem in stress test.
Any suggestions?
There is a
Shaw Graham George wrote:
The problem is that, on Windows at least, my server doesn't appear to
get the SSL shutdown notify packet, for some reason. So, if that is
to be expected, I'm looking for an alternative way of detecting the
closure.
I've now tested it on Linux, and the existing code
Shaw Graham George wrote:
Sure.
1. The server receives the HTTP request, using SSL_read() and
SSL_pending(). The request contains a Keep-Alive request.
2. The server writes the data out to another process.
3. The server then it sits on an event handler that multiplexes a
select() (or
Shaw Graham George wrote:
The sequence of events goes like this:
1. The SSL handshake proceeds as normal.
2. The client puts an HTTP request
3. The server gets the HTTP request
4. The client then executes an (unexpected) SSL shutdown
5. The server puts the HTTP response
Here I might
Here is my take on it, I maybe completely off target but here goes.
David Lobron wrote:
21:08:30.190534 CLIENT.39044 SERVER.8443: P 844:1025(181) ack 4827 win
65535 nop,nop,timestamp 173778704 299402767 (DF)
This is 181 bytes sent to SERVER. Presumably the GET x and
headers all in
David Lobron wrote:
2007-07-26 20:18:04.375 [3317] GS: Got response from sendDataPending
2007-07-26 20:18:04.376 [3317] GS: Calling poll with timeout 6
2007-07-26 20:18:04.376 [3317] GS: Checking poll results
2007-07-26 20:18:04.376 [3317] GS: calling SSL_write on buffer of length
1281
So if you actually read the Wikipedia page (a previous poster has kindly
pointed you at) you should end up at:
http://tools.ietf.org/html/rfc2440#section-6
Darryl
Jeremiah Martell wrote:
On 7/5/07, Carlo Milono [EMAIL PROTECTED] wrote:
Radix-64 - if you want the PGP/GPG stuff.
See:
brajesh tiwari wrote:
Can some one please tell me what may be the problem here.
Thank you very much.
I think the problem may be a bug in your program.
HTH
PS - How do you seriously expect help in debugging your program from a
mailing list. Yes, it is valid for your application code to
Victor Duchovni wrote:
On Wed, Mar 07, 2007 at 03:34:31AM +0100, Vladislav Marinov wrote:
This is why I want to extract information about who is the hostname/IP
participating in the TLS handshake and compare it to the Common Name
field in the certificate.
This makes no sense, the client could
Sergey S. Levin wrote:
1. If i use FileZilla and SSL connection - it works on 100% of speed.
I dont know what FileZilla is, but which SSL implementations is used and
what key exchange protocol and what symmetric cipher did it choose ?
2. The processor load is just 5% so, this should not
Sergey S. Levin wrote:
Why the data transfer speed of the OpenSSL client and server is nearly
10 times slower then when using the regular sockets? The code of the
standard samples of client and servers are used.
Are you also measuring the time it takes to setup the SSL connection or
are you
Marek Marcola wrote:
I've one query regarding SSL_write call provided by OpenSSL
library. The SSL_write could return with READ_ERROR or WRITE_ERROR
with partial writing of data. While re-attempting to send the data
once again SSL_Write expects the same arguments as that of the
previous one.
I would guess anything within the last few years.
Lets take a system:
$ uname -a
Linux me.foobar.com 2.6.18 #1 SMP Sun Sep 24 21:09:55 BST 2006 x86_64
x86_64 x86_64 GNU/Linux
$ gcc -v
Using built-in specs.
Target: x86_64-redhat-linux
Configured with: ../configure --prefix=/usr
Mark wrote:
I think it would be helpful for me. If we need to prevent calling
SSL functions on the same object (i.e. SSL_read() and SSL_write())
from different threads then I would think that OpenSSL would not need
any internal synchronisation, unless it creates its own threads
internally.
GUIRY Aroun wrote:
If I send a new packet from the client I can read the missing packets,
but not the new one.
I use non-blocking sockets.
Are you on linux ?
Can you run 'strace' or 'strace -p pid' and paste the relevant parts
of the output to the list.
Darryl
GUIRY Aroun wrote:
Thanks Darryl for your help.
I wrote that when I send a new packet from the client I can read the
missing
packets, but not the new one But in fact I can read the missing packets
and a part of the second packets.
Here is the trace. I send a trame of 10 bytes from the
Jon Perkin wrote:
Apologies if this is the wrong place for my query, as I'm not sure how to
track down whether my problem lives in core OpenSSL, in the Perl OpenSSL
modules, or in the LWP modules I'm trying to use them via.
Even if I did know the answer, your not going to get it by posting the
Friedrich Dominicus wrote:
According to threads(3) and also mentioned in network security with
OpenSSL from O'Reilly one has to provide callback functions for using
OpenSSL with threads.
The callbacks abstract the thread locking/mutex requirements inside
OpenSSL library to manipulate its
Girish Venkatachalam wrote:
I don't know what is supposed to happen in theory, but
in practice I have found select() to be quite a
disaster in informing me when a socket becomes
writable. I have seen this on both Linux and FreeBSD.
select() is very useful and an elegant solution for
Marek Marcola wrote:
For example:
/* check socket error state - only if val == 0 after this call
* connection is properly established.
*/
len = sizeof(int);
if (getsockopt(fd, SOL_SOCKET, SO_ERROR, (void *) state, len) 0) {
goto err;
Bu Bacoo wrote:
Instead of modifying the BIO, I've also tried to set it's socket to
non-blocking mode. Same result, BIO_do_connect returns -1
BIO* pBio = BIO_new_connect((char*)conn.c_str());
BIO_socket_nbio(BIO_get_fd(pBio,NULL), 1);
BIO_do_connect(pBio); //returns -1
On 7/22/06, Bu Bacoo
Marek Marcola wrote:
[EMAIL PROTECTED] writes:
For the moment, i have a kind of supervisor which,
accept a connection, read some datas on the socket and
then start the process which is able to handle this
datas. ( using createprocess/execv). The socket's
handle is shared to this process and
Gayathri Sundar wrote:
Thanks Richard..but I was thinking only SSL RECORDS with Record Type APP
DATA
Contain application data!!! If I can ensure that only complete SSL Records
of Type
Handshake, Change cipher spec, and Alerts are given to OpenSSL, it can
process it rite?
This way how can
Dmitriy Khodos wrote:
The function fails if the PID does not match. However,
since PID is obtained by calling getpid(2), under Linux it is going to be
different in different threads.
It depends which version of Linux you are running and which thread
implementation you have at runtime. The
Girish Venkatachalam wrote:
But did you factor the fact that an SSL renegotiation
or handshake can happen anytime during the
conversation?
Thats not strictly true, the receiving end does have a tiny bit of
control over when to process it. From recent discussion in this list my
Henrik Thuermer wrote:
At 15:20 17.07.2006 -0700, you wrote:
Yes, I know that. But in our case there is no renegotiation: SSL_write
never returns an error and if the SSL_read return value is below zero
SSL_get_error returns only WANT_READ. In that case there was never someting
in the outgoing
Here is another interesting one,
What I mean by a null write is allow the write machinery to flush and
emit outstanding data or deal with renegotiation requests that need
write operations to be performed but I wont want to send any new
application data ?
The man page for SSL_write()
Henrik Thuermer wrote:
If we receive some data we process it via one BIO_write call followed by
SSL_read calls until the call to SSL_read fails with SSL_get_error() ==
SSL_ERROR_WANT_READ or SSL_read returns no more data (SSL_ERROR_WANT_WRITE
is also handled correctly - I hope). Then we stop
Marek Marcola wrote:
SSL protocol differs in server_key_exchange packet
(with may be used not only for export restriction).
This requires temporary RSA key in context.
If you add to server initialization routine something like:
RSA *rsa;
Marek Marcola wrote:
Many applications generate a static one, can the same exact key be
re-used without any security considerations for unrelated sessions ?
Should a highly secure application generate a new one for every connection?
In this case (export restriction) generating RSA 512 bit key
Leon wrote:
I hope the OpenSSL maintainers heard this cry (even if it is a small
cry) and will at some point decide to use a better method than select.
This got patched in CVS yesterday for Linux.
David Schwartz wrote:
A patch to use 'poll' instead of 'select' where it's available
Zhang, Long (Roger) wrote:
I have created a TLS connection with SSL_connect(ssl) successfully.
...SNIP..
Ah you're asking on the correct list now, you might get a useful answer.
I think you may need to call SSL_clear() after SSL_shutdown() and before
SSL_connect().
But if you are re-using
Krishna M Singh wrote:
We are using the multiple contexts (although not same as thread count
i.e. 10 Contexts for 3 threads).. Select call may be failing as the
default FD_SET_SIZE is 255 on most systems and thus in case u want to
handle 1000 sockets u need to increase the limit.. There is #def
Bodo Moeller wrote:
On Thu, Jun 22, 2006 at 10:41:14PM +0100, Darryl Miles wrote:
SSL_CTX_set_mode(3)
SSL_MODE_ACCEPT_MOVING_WRITE_BUFFER
Make it possible to retry SSL_write() with changed buffer
location (the buffer contents must stay the same). This is not the
default to avoid
Leon wrote:
$ grep __FD_SETSIZE /usr/include/bits/*.h
/usr/include/bits/typesizes.h:#define __FD_SETSIZE1024
This is the maximum number of fd's the fd_set type holds by default.
Maybe it would be possible to stop the crashes and override this with
some ugly stack paddings:
If
Darryl Miles wrote:
But I can see your point now, if it is an OpenSSL problem you are pretty
much stuck. For example if OpenSSL uses select() to sleep for
/dev/random but your application is already into the 1500th active file
descritor. Then OpenSSL is pretty much hosed for using select
Bodo Moeller wrote:
On Mon, Jun 26, 2006 at 12:35:57PM +0100, Darryl Miles wrote:
Yes. During the first call to SSL_write(), OpenSSL may take as many
bytes as fit into one TLS record, and encrypt this for transport.
Then SSL_write() may fail with WANT_WRITE or WANT_READ both before and
after
Kyle Hamilton wrote:
On 6/26/06, Darryl Miles [EMAIL PROTECTED] wrote:
I still have not gotten to the bottom of the entire scope of
situation(s) can cause an SSL_write() to return -1 WANT_READ. If its
only renegotiation that can; then this is always instigated by a
SSL_renegotiate() (from my
Bodo Moeller wrote:
On Mon, Jun 26, 2006 at 02:04:47PM +0100, Darryl Miles wrote:
Bodo Moeller wrote:
On Mon, Jun 26, 2006 at 12:35:57PM +0100, Darryl Miles wrote:
Yes. During the first call to SSL_write(), OpenSSL may take as many
bytes as fit into one TLS record, and encrypt
Leon wrote:
On Mon, 2006-06-26 at 14:24 +0200, Marek Marcola wrote:
OK weirdness going on here. I've added the RAND_load_file() command to
the beginning of my program and it does not make a difference.
With a 1000 threads I get a call to RAND_poll() only with the first
connection and not with
Randy wrote:
This code compiles and links fine. If I uncomment the SSL_new line I get
undefined symbol: ssl_x
SSL_CTX *ctx;
// SSL_new *ssl_x;
SSL_new is not a type, but a function: int SSL_new(SSL *);
#include openssl/ssl.h
SSL *ssl_x;
should work.
HTH
Darryl
Darryl Miles wrote:
SSL_new is not a type, but a function: int SSL_new(SSL *);
Opps:
SSL_new is not a type, but a function: SSL *SSL_new(SSL_CTX *);
So then you'd use:
ssl_x = SSL_new(ctx);
__
OpenSSL Project
Randy wrote:
Unfortunately that is how I orginally had it but that generates the same
error.
SSL *ssl_x;
Generates
UX:acomp: ERROR: curl_dip.c, line 271: undefined symbol: ssl_x
UX:acomp: WARNING: curl_dip.c, line 457: assignment type mismatch
*** Error code 1 (bu21)
Mark wrote:
SSL_MODE_ACCEPT_MOVING_WRITE_BUFFER is likely for those OSes (*glares
at Windows in particular*) which require locking allocated memory in
place, performing an operation on it, and then unlocking it (to allow
the OS to manage the placement of the memory block in physical
memory).
Torsha Banerjee wrote:
Can anyone please please tell me how to received the messages from the
group as digest instead of individual mails. My mailbox is getting
bombarded with these mails.
Go back to where you signed up ?
Maybe that was at http://www.openssl.org/support/
I'm not sure if
David Schwartz wrote:
David you are bringing completely unrelated issues into the situation.
No, you are failing to understand my argument.
A Kernel does its job of arbitration like this on a shared/duped file
descriptor that both processes have as fd=4:
Thread/Process A
Marek Marcola wrote:
Your next argument will be:
if you do select() and space shuttle is flying ...
I am in complete agreement here.
The crux of the situation is that I'm (we're) saying its possible to
have working OpenSSL blocking mode that uses a blocking socket which
conforms the to
1 - 100 of 122 matches
Mail list logo
