28 May
2009
28 May
'09
5:19 a.m.
while compiling modules/tls, i get a some warnings:
tls_config.c: In function ??parse_ipv6??:
tls_config.c:67: warning: implicit declaration of function ??str2ip6??
tls_config.c:67: warning: assignment makes pointer from integer without
a cast
and
tls_init.c:71:10: warning: #warning "openssl zlib compression bug workaround
enabled"
tls_init.c:89:3: warning: #warning "openssl < 1.0: no TLS extensions or server
name support"
and
tls_server.c: In function ??tls_h_nonblocking_write??:
tls_server.c:811: warning: label ??again?? defined but not used
how to get rid of them (the last looks easy)? do i have wrong version
of openssl dev package?
ii libssl-dev 0.9.8g-15+lenny1 SSL development
libraries, header files and
by the way, why is tls implementation based on openssl instead of
gnutls?
-- juha
28 May
28 May
5:47 a.m.
On May 28, 2009 at 12:19, Juha Heinanen <jh(a)tutpro.com> wrote:
while compiling modules/tls, i get a some warnings:
tls_config.c: In function ??parse_ipv6??:
tls_config.c:67: warning: implicit declaration of function ??str2ip6??
tls_config.c:67: warning: assignment makes pointer from integer without
a cast
This is strange, I do not get it. str2ip6 is defined in resolve.h, which
is included by tls_config.c, so you shouldn't get it either...
and
tls_init.c:71:10: warning: #warning "openssl zlib compression bug workaround
enabled"
There are a lot of bug workarrounds for specific openssl versions. See
the modules's README for more details.
tls_init.c:89:3: warning: #warning "openssl <
1.0: no TLS extensions or server name support"
and
tls_server.c: In function ??tls_h_nonblocking_write??:
tls_server.c:811: warning: label ??again?? defined but not used
That's a function which made it in by mistake during the merge. I wanted
to use for tls async support, but that's not ready it. It can safely be
commented out completely for now.
how to get rid of them (the last looks easy)? do i have wrong version
of openssl dev package?
It depends, if you want to use TLS extensions (for now this means
getting the TLS server name extension from the script via the
@tls.serverName select or the &tls_peer_serve_name pvar) then you need
at least the 1.0 version of openssl. If you don't you can stick with the
older version.
ii libssl-dev 0.9.8g-15+lenny1 SSL development
libraries, header files and
by the way, why is tls implementation based on openssl instead of
gnutls?
Because at the time the first tls implementation started, gnutls was
very new.
While it's true that openssl has a lot of bugs (especially a lot of
unchekced mallocs() which are present even in modern versions and some
multiprocess problems which seem to be solved in the latest versions),
at least we know them and we have a lot of workarounds for various
openssl versions. Since so far nobody tried a gnutls implementation we
do not know if it stands better or if we'll need again a ton of
new workarounds.
The problem with a new implementation is that it will need a lot of
testing and so far it looks like extremely few people are using
ser/k/openser with tls in a demanding environment (the best proof for
this is that the k/openser implementation had some critical bugs in it
that would have cause crashes under heavy use).
Andrei
8:02 a.m.
Andrei Pelinescu-Onciul writes:
This is strange, I do not get it. str2ip6 is defined
in resolve.h, which
is included by tls_config.c, so you shouldn't get it either...
andrei,
it is defined if USE_IPV6 is defined, which i have not defined. the
reason is that i don't believe that ipv6 will be used in production,
before i have retired from this business. my vote it have USE_IPV6 off
by default.
anyway, looks like some ifdefs are required in tls_config.c.
-- juha
3:26 p.m.
Andrei Pelinescu-Onciul writes:
It depends, if you want to use TLS extensions (for now
this means
getting the TLS server name extension from the script via the
@tls.serverName select or the &tls_peer_serve_name pvar) then you need
at least the 1.0 version of openssl. If you don't you can stick with the
older version.
without TLS server name extensions, TLS does not work in multi-domain
environment? if so, looks like 1.0 is a must. the bad news is that 1.0
is not included any any debian release (not even unstable). looks like
openssl in debian is at dead end.
-- juha
29 May
29 May
6:28 a.m.
On 28-05 22:26, Juha Heinanen wrote:
Andrei Pelinescu-Onciul writes:
It does, but you have to use a separate IP address for each domain.
It depends, if you want to use TLS extensions
(for now this means
getting the TLS server name extension from the script via the
@tls.serverName select or the &tls_peer_serve_name pvar) then you need
at least the 1.0 version of openssl. If you don't you can stick with the
older version.
without TLS server name extensions, TLS does not work in multi-domain
environment? if so, looks like 1.0 is a must.
It's not a must, but configuring tls in multi-domain mode becomes slightly
more complicated.
By the way, is anyone aware of a user agent that supports TLS with the server
name extension?
Jan.
5691
days inactive
5692
days old
4 comments
3 participants
participants (3)
-
Andrei Pelinescu-Onciul -
Jan Janak -
jh＠tutpro.com