Hi,
... and now version (4) with the dynamic-wind in the correct place:
I think the logic is correct now, just two small cosmectic issues:
diff -upr v1.6.4/openssl.import.scm v1.6.4-andyjpb-fix-4/openssl.import.scm
--- v1.6.4/openssl.import.scm 2014-11-23 02:37:31.235897645 +
+++
On 23/11/14 18:38, Florian Zumbiehl wrote:
Hi,
;; close
(lambda ()
(when (startup #t)
(if outbuf
- (begin
- (output outbuf)
- (set! outbuf )))
+ (begin
+ (unbuffered-write outbuf 0 outbufsize)
Hi,
... and now version (4) with the dynamic-wind in the correct place:
-
$ diff -upr v1.6.4-andyjpb-fix-3 v1.6.4-andyjpb-fix-4
Binary files v1.6.4-andyjpb-fix-3/openssl.import.so and
v1.6.4-andyjpb-fix-4/openssl.import.so differ
diff -upr v1.6.4-andyjpb-fix-3/openssl.scm
Hi,
I'd be glad if some of you could test this out and tell me what you
think about it
Can you give some tips for how to test this from a spiffy applications?
I usually just pass in ssl-accept instead of tcp-accept.
[...]
Hello,
actually I have very little experience with spiffy, but
Hi,
;; close
(lambda ()
(when (startup #t)
(if outbuf
- (begin
-(output outbuf)
-(set! outbuf )))
+(begin
+ (unbuffered-write outbuf 0 outbufsize)
+ (set! outbufsize 0)))
On Tue, 28 Oct 2014, Florian Zumbiehl wrote:
[...]
I am not sure I understand what you mean--you never can protect against a
client that doesn't want to protect the session, they always could just
publish the session key, or the decrypted data, or whatever. The protection
should always focus on
Hi,
that's right, but you can also try to protect against a client that
tries to obtain information from the server side to which it isn't
So, you'd actually be protecting the association between the server and the
legitimate client against an unauthorized third party, no?
entitled. However,
Hi,
Therefore I took another route: The existing procedures keep their
current defaults, but there is a new set of object constructors that
uses only keyword arguments and configures things in a more secure
way by default.
That seems sensible to me, in particular as making existing APIs
On Tue, Oct 28, 2014 at 07:35:00AM +0100, Florian Zumbiehl wrote:
Hi,
Therefore I took another route: The existing procedures keep their
current defaults, but there is a new set of object constructors that
uses only keyword arguments and configures things in a more secure
way by
On Tue, 28 Oct 2014, Florian Zumbiehl wrote:
[...]
Regarding specific improvements:
[procedure] (ssl-make-client-context* #!key
((protocol symbol) 'tls) ((cipher-list string|list) HIGH)
((certificate-authorities string) #f)
((certificate-authority-directory string) #f)
Florian Zumbiehl scripsit:
I am not sure I understand what you mean--you never can protect against a
client that doesn't want to protect the session, they always could just
publish the session key, or the decrypted data, or whatever. The protection
should always focus on third parties that
Hi,
Thanks for this Thomas!
I'd be glad if some of you could test this out and tell me what you
think about it :-)
Can you give some tips for how to test this from a spiffy applications?
I usually just pass in ssl-accept instead of tcp-accept.
Regards,
@ndy
--
andy...@ashurst.eu.org
On Mon, 27 Oct 2014, Andy Bennett wrote:
[...]
I'd be glad if some of you could test this out and tell me what you
think about it :-)
Can you give some tips for how to test this from a spiffy applications?
I usually just pass in ssl-accept instead of tcp-accept.
[...]
Hello,
actually I
On Thu, 16 Oct 2014, Thomas Chust wrote:
[...]
So I would like to poll for opinions from people on this list concerning this
situation. Do you think the default options in the OpenSSL egg should be
hardened? Do you think more options should be introduced? Is compatibility
with the rest of
Thomas Chust ch...@web.de writes:
So I would like to poll for opinions from people on this list
concerning this situation. Do you think the default options in the
OpenSSL egg should be hardened? Do you think more options should be
introduced? Is compatibility with the rest of the internet a
On Thu, 16 Oct 2014, Sascha Ziemann wrote:
[...]
I think it is a good idea to make TLS the default. [...] I think it is
sufficient to enable SSL with a parameter or environment variable. I
propose:
I_DONT_CARE_ABOUT_SECURITY=yes
[...]
... and there I was thinking that was implicit in the
Thomas Chust scripsit:
... and there I was thinking that was implicit in the use of SSL/TLS
in the first place ;-)
Security, like privacy, exists in the individual human mind alone: die
Gedanken sind frei. Beyond that, 15th century tradecraft is still the
best advice: meet someone around
On Thu, 16 Oct 2014, Florian Zumbiehl wrote:
[...]
I just wanted to point out that we still have a bunch of patches lying
around that among other things implement security improvements:
openssl: add support for TLS 1.1 and 1.2
openssl: add functions ssl-set-reneg-legacy-server-connect!,
Hi,
thanks for the heads up, I had totally forgotten about these
patches. Can they be found somewhere online? I'd like to take a look
again, perhaps they aren't that hard to incorporate.
You probably didn't know about them yet, and they are unpublished so far, I
just have pointed out the
Hi,
IIRC we were waiting for andyjpb and company to fix the breakage introduced
by the buffering patch so we could pull in current upstream and then push
the patches or something ...
Oops... sorry. I can't find the mail relating to the details of the
breakage. Please can someone remind me and
Hello,
Mario Domenech Goulart raised the issue that the OpenSSL egg by default
creates connections that can use any of the SSLv2, SSLv3 or TLSv1.x
protocols, depending on the capabilities of the remote peer.
This default is not particularly secure, especially when considering the
recently
Hi Thomas!
So I would like to poll for opinions from people on this list concerning
this situation. Do you think the default options in the OpenSSL egg
should be hardened? Do you think more options should be introduced? Is
compatibility with the rest of the internet a concern at all? ;-)
We
On Thu, 16 Oct 2014, Andy Bennett wrote:
[...]
Having said that, I'm not sure which clients on which operating systems
are SSL 3.0 only.
[...]
Hello Andy,
if I understand the situation correctly, almost nobody uses SSLv3 since it
was quickly superseded by the newer TLS variants. But the
23 matches
Mail list logo
