How about 256 on the stack?
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
bn/bn_prime.c
static int probable_prime(BIGNUM *rnd, int bits)
{
int i;
prime_t mods[NUMPRIMES]; ==
BN_ULONG delta, maxdelta;
This one is also excessive.
The problem is that even on OS's with dynamic thread stack if you do cause
a stack overrun, the entire process
On Thu, Jul 23, 2015 at 08:21:11PM +, Viktor Dukhovni wrote:
Postfix happily sends session tickets and resuming sessions even
though it is using SSLv23_client_method(), and there is no server-side
session cache (I made sure the client connets to a different server
process between the
On Fri, Jul 24, 2015 at 01:46:36AM +0300, Jouni Malinen wrote:
I'd assume this is with the more standard TLS SessionTicket which is not
what EAP-FAST is..
Correct.
The order of events is:
/* Once only */
ctx = SSL_CTX_new(SSLv23_client_method());
/* Per connection */
On Thu, Jul 23, 2015 at 09:22:04PM +0300, Jouni Malinen wrote:
I used to use SSL_CTX_new(TLSv1_method()) to initialize SSL_CTX for
various TLS-based EAP methods. This worked fine with EAP-TLS,
EAP-PEAP, EAP-TTLS, and EAP-FAST. However, it did not allow OpenSSL to
negotiate TLS v1.1 or v1.2 to
Any thoughts much appreciated.
~Kannan N.
-Original Message-
From: openssl-dev [mailto:openssl-dev-boun...@openssl.org] On Behalf Of Kannan
Narayanasamy -X (kannanar - HCL TECHNOLOGIES LIMITED at Cisco)
Sent: Wednesday, July 22, 2015 4:54 PM
To: openssl-dev@openssl.org
Subject:
On Thu, Jul 23, 2015 at 01:19:24PM +, Ian McFadries (imcfadri) wrote:
I have encountered a problem with EAP-FAST PACs when switching our
implementation of OpenSSL from a context that supports TLSv1.0 only to a
context that supports negotiation to the highest available TLS version.
Just
Hello,
for certificates which get renewed -- mine do twice a year, for
example -- the fingerprint changes
?0[tmp]$ openssl x509 -fingerprint -noout cert.old
SHA1 Fingerprint=00:10:F0:2C:EA:50:1F:11:FE:8D:CC:A0:A9:40:91:A2:D0:4D:65:4E
?0[tmp]$ openssl x509 -fingerprint -noout cert.crt
I have encountered a problem with EAP-FAST PACs when switching our
implementation of OpenSSL from a context that supports TLSv1.0 only to a
context that supports negotiation to the highest available TLS version.
For EAP-FAST the PAC opaque is loaded into the SSL tlsext_session_ticket using
bn/bn_prime.c
static int probable_prime(BIGNUM *rnd, int bits)
{
int i;
prime_t mods[NUMPRIMES]; ==
BN_ULONG delta, maxdelta;
This one is also excessive.
The problem is that even on OS's with dynamic thread stack if you do cause
a stack overrun, the entire process
I do call SSL_CTX_set_options(ctx, SSL_OP_NO_SSLv2|SSL_OP_NO_SSLv3) so the
client hello message starts with a TLSv1.2, and will negotiate as low as
TLSv1.0. Under this context, the ssl23_client_hello method is being called
-Original Message-
From: openssl-dev
On Thu, Jul 23, 2015 at 02:21:31PM +, Ian McFadries (imcfadri) wrote:
I do call SSL_CTX_set_options(ctx, SSL_OP_NO_SSLv2|SSL_OP_NO_SSLv3) so
the client hello message starts with a TLSv1.2, and will negotiate as low
as TLSv1.0. Under this context, the ssl23_client_hello method is being
On Tue Jan 27 10:19:14 2015 -0500, Rich Salz rs...@openssl.org wrote:
Remove OPENSSL_NO_RFCF3779.
Hm, that hurts. The UEFI build was using that, as it doesn't provide a
strspn() function. And doesn't need or want this functionality.
--
David WoodhouseOpen Source
From: Long, Qin qin.l...@intel.com
Some environments, such as 32-bit UEFI, have strict limits on stack size.
Using a 4KiB buffer on the stack for reading from p7bio is somewhat
excessive, so allocate it on the heap instead.
---
Alternatively, we could leave it on the stack and reduce it to 256
Hm, that hurts. The UEFI build was using that, as it doesn't provide a
strspn() function. And doesn't need or want this functionality.
Hm. There's always going to be some extensions that not everyone wants... No
good ideas here.
--
Senior Architect, Akamai Technologies
IM:
On Thu, 2015-07-23 at 16:23 +, Salz, Rich wrote:
Hm, that hurts. The UEFI build was using that, as it doesn't
provide a
strspn() function. And doesn't need or want this functionality.
Hm. There's always going to be some extensions that not everyone
wants... No good ideas here.
If I were to resurrect it as part of the patchset to make the UEFI
build work sanely, would you object to that?
I've got no problem with that.
It's also been suggested that certain things could be elided simply by
OPENSSL_SYS_UEFI rather than OPENSSL_NO_xxx. But I really don't like
that
Hi guys,
I am a novice about openssl. I encounter linker error when I try to compile evp
demos which locate openssl/demos/evp.
My computer info is:
Darwin Kernel Version 14.4.0: Thu May 28 11:35:04 PDT 2015;
root:xnu-2782.30.5~1/RELEASE_X86_64
And I use both gcc and clang with
18 matches
Mail list logo
