Hi,
this is a question to the VMS folks out there.
A few days ago, I took SSL_TASK out of the OpenSSL master branch (that
is, the files crypto/bio/bss_rtcp.c and ssl/ssl_task.c). It never
really belonged in OpenSSL but stayed there for reasons only
historians can tell at this point.
I'm current
On 5/4/15 11:11 am, Jeffrey Walton wrote:
> On Sat, Apr 4, 2015 at 11:03 PM, Michael Clark
> wrote:
>> ...
>> Now works on Darwin/OSX: https://github.com/michaeljclark/async_tls_test
>>
>> Just working through poll peculiarities on Linux. Thanks.
> Related: libevent (http://libevent.org/) does a
On Sat, Apr 4, 2015 at 11:03 PM, Michael Clark wrote:
> ...
> Now works on Darwin/OSX: https://github.com/michaeljclark/async_tls_test
>
> Just working through poll peculiarities on Linux. Thanks.
Related: libevent (http://libevent.org/) does a pretty good job of
abstracting that away. I believe i
On 5/4/15 7:35 am, Michael Clark wrote:
> On 5/4/15 7:32 am, Graham Leggett wrote:
>> On 04 Apr 2015, at 9:46 PM, Michael Clark wrote:
>>
>>> I am having an issue where the server crashes on subsequent connections
>>> *if* I close the connection file descriptor. See the note in
>>> openssl_async_e
> by randomly interspersing flush commands into the data stream (description
> and example implementation https://github.com/wnyc/breach_buster)?
> It's not perfect but for some use cases better than having no compression at
> all.
Flushing the stream seems like an application-level thing to do, a
> > Modulus:
> > 00:9a:18:ca:4b:94:0d:00:2d:af:03:29:8a:f0:0f:
The leading zero is so that you don't confuse it with a sign bit.
___
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/o
On 5/4/15 7:32 am, Graham Leggett wrote:
> On 04 Apr 2015, at 9:46 PM, Michael Clark wrote:
>
>> I am having an issue where the server crashes on subsequent connections
>> *if* I close the connection file descriptor. See the note in
>> openssl_async_echo_server.cc on line 239. If I leak a file des
On 04 Apr 2015, at 9:46 PM, Michael Clark wrote:
> I am having an issue where the server crashes on subsequent connections
> *if* I close the connection file descriptor. See the note in
> openssl_async_echo_server.cc on line 239. If I leak a file descriptor
> and the next connection uses a new fd
In fact I did not use any store (thus openssl should be correct). I just
tested the logic (openssl verify -CAfile $ca_file $file) and found that it
is a little tricky to find the issuer of a certificate (e.g.,
name/sn-based, key id based), and the behavior is unpredictable. Sometimes
a certificate
On 5/4/15 3:46 am, Michael Clark wrote:
> SSL_free(ssl_conn.ssl);
> // TODO - crashes on subsequent connections in SSL_do_handshake if we
> close the fd.
> //
> ssl_lib.c::SSL_do_handshake::s->method->ssl_renegotiate_check(s);
> //Why? reuse of same fd number for subsequent c
> OpenSSL could be more flexible or friendly in its building strategy.
> But that could move into the "which directory" problem rather quickly.
>
This is kind of interesting. Looking at RFC 5280, section 4.2.1.1
Authority Key Identifier (p. 26):
The value of the keyIdentifier field SHOULD be d
> What makes you think it is incorrect to check the Key
> Identifier (where present) before checking a signature
> against a key?
An X.509 certificate does one thing: it binds a public key to an
identity. In PKI, a public key alone means nothing because trust is
placed in principals or issuers.
I
Hi,
I am trying to write the simplest possible example of an async TLS
client and server using non-blocking IO and
SSL_ERROR_WANT_READ/SSL_ERROR_WANT_WRITE events. The main purpose is to
test the async IO code paths with a). an absence of all of the complex
options in s_client and s_server, and b)
On Sat, Apr 4, 2015 at 11:15 AM, Viktor Dukhovni
wrote:
> On Fri, Apr 03, 2015 at 07:53:59PM +, Salz, Rich wrote:
>
> My own builds of OpenSSL have always (over a decade now) been
> "no-zlib".
>
That's kind of interesting (to me). Did you disable it because you
were suspicious of compression l
On Fri, Apr 3, 2015 at 3:53 PM, Salz, Rich wrote:
> I am thinking about removing compression and would like to know what the
> community thinks.
>
What the community thinks does not matter.
If your threat model includes recovery via compression through
protocols like TLS, HTTPS and SPDY, then you
On Sat, Apr 04, 2015 at 05:31:37AM +0200, Jakob Bohm wrote:
> (top posting like the rest of the thread)
>
> What makes you think it is incorrect to check the Key
> Identifier (where present) before checking a signature
> against a key?
>
> What other reasonable purpose could the Key Identifier
>
On 03.04.15 21:53, Salz, Rich wrote:
> But on a larger scale, does anyone use TLS compression? It has
> certainly caused problems with HTTP (see
> http://en.wikipedia.org/wiki/CRIME). And the best practice these days is
> to do it at the application layer, and feed the compressed bytes down to
> T
On Fri, Apr 03, 2015 at 07:53:59PM +, Salz, Rich wrote:
> I am thinking about removing compression and would like to know
> what the community thinks.
At the very least drop "zlib-dynamic" support. This has caused
"DLL-hell" on some platforms, when a dynamically loaded libz
conflicts with a
On Fri, Apr 03, 2015 at 07:53:59PM +, Salz, Rich wrote:
>
> And the best practice these days is to do it at the application
> layer, and feed the compressed bytes down to TLS.
The BREACH attack makes use of that.
Kurt
___
openssl-users mailing li
19 matches
Mail list logo
