> From: owner-openssl-us...@openssl.org On Behalf Of David Schwartz
> Sent: Sunday, 01 May, 2011 06:03
> On 5/1/2011 1:34 AM, derleader mail wrote:
>
> > I'm going to use stream protocol - TCP/IP. Here is the
> template source
> > code of the server without the encryption part
>
> We mean application protocol.
>
> > while (1) {
> > sock = accept(listensock, NULL, NULL);
> > printf("client connected to child thread %i with pid %i.\n",
> > pthread_self(), getpid());
pthread_t and pid_t are not required to be int and sometimes aren't.
I don't think they're even required to be any integers.
> > nread = recv(sock, buffer, 25, 0);
> > buffer[nread] = '\0';
Where buffer is char[25]. If the client always sends 25 bytes
(or more) this will write outside the space allocated for buffer[].
This is undefined behavior in C and the program can fail arbitrarily.
On today's systems usually this will 'accidentally' work,
but you have no confidence of that in the future.
Either make maximum read at least one byte smaller than buffer,
or buffer at least one byte larger than maximum read.
Also, recv() returns -1 if error; storing to buffer[-1]
is also undefined and more likely to actually screw up.
For that matter, accept() can fail and return not a valid socket,
in which case the recv() and send() can't succeed.
> > printf("%s\n", buffer);
If this is the only reason you wanted null termination,
you could do printf("%.*s\n",nread,buffer) instead.
> > send(sock, buffer, nread, 0);
> > close(sock);
> > printf("client disconnected from child thread %i with pid %i.\n",
> > pthread_self(), getpid());
> > }
> > }
>
> This code isn't very helpful. It just reads and writes the very same
> data. Nothing in this code tells us, for example, how to identify a
> complete message.
>
Unless the messages are fixed-length 25 bytes. I've seen crazier.
> You could interpose an encryption protocol that also imposed no such
> requirements. You would need to work out your own padding though.
> Blowfish is a block encryption algorithm and cannot encrypt just a
> single byte. So if you only read one byte, you'd need to pad
> it before
> encryption and then you'd need some way to remove the padding on the
> other end.
>
Not quite; OP's earlier code had Blowfish *CFB*,
a stream mode that can handle any number of bytes.
(The mode itself can handle any number of bits, but
the OpenSSL API doesn't handle sub-byte amounts.)
However a stream mode is generally more vulnerable to
bit-flipping unless authenticated, which the OP didn't.
Also his 'test' had a fixed IV (and key),
but maybe that was only a test.
> I would strongly urge you to just use SSL. It is designed for
> *exactly*
> this purpose.
>
Agree there.
Also it should be noted session caching only helps
if both ends support (and allow) it; it is optional.
If you write both programs and use OpenSSL, it's easy,
but in some other situations it might not be.
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users@openssl.org
Automated List Manager majord...@openssl.org
