e the client needs to take some
measure. The client happily keeps sending data.
Any help on how to resolve this would be greatly appreciated.
Best regards,
Fredrik Jansson
Hi!
I have managed to deadlock OpenSSL while running in FIPS mode.
The locking functions are setup according to mttest.c and th-lock.c using
pthread_mutex_.
Please note I have NOT explicitly set a thread id function.
Then env is:
openssl-1.0.1e
openssl-fips-2.0.5
RHEL 6 - 32 bit.
Please let me
Hi!
Note, this is OpenSSL 1.0.1c.
sha.h: int SHA512_Init(SHA512_CTX *c);
evp.h: const EVP_MD *EVP_sha512(void);
Best regards,
Fredrik
On Fri, Oct 4, 2013 at 9:44 AM, Gnanasekar R wrote:
> Hi,
>
> I would like to know if OpenSSL has support for SHA-512/224 and
> SHA-512/256. I see init functio
Hi!
I am trying to use DTLS with PSK (cipher: SSL_TXT_PSK). Everything works
well if I don't set OpenSSL in FIPS mode (FIPS_mode_set(1)).
If I do, I get crashes as below where p =0;
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7fffddffb700 (LWP 15278)]
0x7
t;
}
before *p == SSL3_MT_CLIENT_HELLO, it works.
Should I report a bug?
Fredrik
On Fri, Oct 25, 2013 at 2:03 PM, Fredrik Jansson <
fredrik.jansson...@gmail.com> wrote:
> Hi!
>
>
> I am trying to use DTLS with PSK (cipher: SSL_TXT_PSK). Everything works
> well if
Sun, Nov 3, 2013 at 4:15 PM, Dr. Stephen Henson wrote:
> On Fri, Oct 25, 2013, Fredrik Jansson wrote:
>
> >
> > I am trying to use DTLS with PSK (cipher: SSL_TXT_PSK). Everything works
> > well if I don't set OpenSSL in FIPS mode (FIPS_mode_set(1)).
> >
>
>
2:31 PM, Dr. Stephen Henson wrote:
> On Mon, Nov 04, 2013, Fredrik Jansson wrote:
>
> > Steve, thanks for getting back!
> >
> > Since I could not reproduce this using s_client and s_server I set out to
> > take the code I am using into a sample project.
> >
>
04, 2013, Fredrik Jansson wrote:
>
> > Thanks, that did it!
> >
> > To try to understand the implications of this, if I add SSL_FIPS
> > to TLS1_TXT_PSK_WITH_AES_128_CBC_SHA and
> TLS1_TXT_PSK_WITH_AES_256_CBC_SHA,
> > am I violating the security policy? AES 128/256
Hi Sravanthi,
I have implemented this as follows:
One thread per listen socket, calling DTLSv1_listen. This thread spawns one
thread per client and those treads call SSL_accept.
The listening threads share a single SSL_CTX, and each call to SSL_new is
protected by a mutex.
Each SSL object has a
I am currently using DTLS v1.1 but with the introduction of v1.2 in OpenSSL
1.0.1f I was hoping to be able to use AES CCM mode.
We use PSK to key DTLS and the resulting algorithm is PSK-AES256-CBC-SHA.
Is it possible to stick with PSK and migrate to AES CCM?
Best regards,
Fredrik
Mar 04, 2014, Fredrik Jansson wrote:
>
>> I am currently using DTLS v1.1 but with the introduction of v1.2 in OpenSSL
>> 1.0.1f I was hoping to be able to use AES CCM mode.
>>
>> We use PSK to key DTLS and the resulting algorithm is PSK-AES256-CBC-SHA.
>> Is it possi
Hi!
Some example code to extract a cert from a P12 file:
BIO* certFile = BIO_new_file("cert path", "r");
PKCS12* p12 = nullptr;
X509* cert = nullptr;
if (!certFile) {
goto done;
}
p12 = d2i_PKCS12_bio(certFile, nullptr);
if (!
I have two CRL, one empty and one with a revoked certificate.
I create a X509_STORE and use X509_STORE_add_crl to add the empty CRL.
When verifying the certificate using the store, it verifies alright.
Then I add the CRL with the revoked cert to the same store, again
using X509_STORE_add_crl.
W
rt_cb function. I can convert the encoded cert to
a X509 structure and return that, but I cannot provide it with a
EVP_PKEY object.
Is there any way I can instruct any of the SSL_CTX, SSL or EVP_PKEY
objects to call a signature function (that I provide) during the
handshake?
Best regards,
Fredrik Ja
Hi Steve!
I will try to take that path, thank you!
//Fredrik
On Mon, Oct 13, 2014 at 6:08 PM, Dr. Stephen Henson wrote:
> On Mon, Oct 13, 2014, Fredrik Jansson wrote:
>
>> Hi!
>>
>> I have a device where I cannot access the client certificate's private
>&g
?
Warm regards,
Fredrik
On Mon, Oct 13, 2014 at 6:08 PM, Dr. Stephen Henson wrote:
> On Mon, Oct 13, 2014, Fredrik Jansson wrote:
>
>> Hi!
>>
>> I have a device where I cannot access the client certificate's private
>> key directly, but have access to verification
Hi!
I am trying to force my TLS 1.2 connection into Suite B mode, but at
handshake I get an error "no shared cipher".
The server code is basically:
SSL_CTX_new(TLSv1_2_server_method());
//ECDSA cert is added to the ctx
SSL_CTX_use_certificate(ctx_, serverCert.cert.get())
SSL_CTX_use_PrivateKey(c
SSL_CTX_set_options(ctx_, SSL_OP_NO_TICKET);
415 SSL_CTX_set_session_cache_mode(ctx_, SSL_SESS_CACHE_BOTH);
416 SSL_CTX_sess_set_remove_cb(ctx_, ssl_remove_session_cb);
417 CertStore::setStoreInCTX(ctx_);
418 }
Warm regards,
Fredrik
On Fri, Nov 14, 2014 at 3:36 PM, Dr. Stephen Henson
Fri, Nov 14, 2014, Fredrik Jansson wrote:
>
>> Hi!
>>
>> Thanks!
>>
>> I am using 1.0.2b3 on both server and client, and I have the call to
>> SSL_CTX_set_ecdh_auto, but still no luck.
>>
>> The exact code is as follows:
>>
>> 358
:77:ba:91:4b:34:4f:94:92:b1:a3:
da:5f:43:13:61:d0:02:bc:27:65:47:ac:ba:4e:79:13:84:cd:
eb:c6:5e:a3:94:e9:fa:48:48:e9:78:f9:d3
On Fri, Nov 14, 2014 at 11:32 PM, Dr. Stephen Henson wrote:
> On Fri, Nov 14, 2014, Fredrik Jansson wrote:
>
>> Hi Steve, thanks for
listed
(among with several others).
Fredrik
On Mon, Nov 17, 2014 at 9:54 AM, Fredrik Jansson
wrote:
> Hi Steve!
>
> I remade the certs as below, but I still get the same error, i.e.
> 1408A0C1:SSL routines:ssl3_get_client_hello:no shared cipher.
>
> Anything else I can try
014, Fredrik Jansson wrote:
>
>> Some more info,
>>
>> SSL_get_ciphers on the server and client:
>> Info2014-Nov-17 10:48:26.961112 All.TLSVerbose
>> ECDHE-ECDSA-AES128-GCM-SHA256
>> Info2014-Nov-17 10:48:26.961114 All.TLSVerbose
>> ECDHE-ECD
hello C
ERROR
139990990374592:error:1408A0C1:SSL routines:ssl3_get_client_hello:no
shared cipher:s3_srvr.c:1398:
shutting down SSL
CONNECTION CLOSED
Warm regards,
Fredrik
On Mon, Nov 17, 2014 at 1:09 PM, Fredrik Jansson
wrote:
> Hi!
>
> I have tried with s_client, and I get the same erro
, 2014 at 1:19 PM, Fredrik Jansson
wrote:
> More tests as you suggested:
>
> openssl s_client -tls1_2 -connect XXX:9103
> openssl s_server -state -tls1_2 -cipher SUITEB128 -accept 9103
>
> Using default temp DH parameters
> ACCEPT
> SSL_accept:before/accept ini
:6b:15:
5d:25:45:59:86:22:f6:de:06:db:0c:60:8e:30:32:45:d6:c6:
01:16:a3:94:9d:cb:4e:fd:a6:6b:a1:73
On Mon, Nov 17, 2014 at 3:06 PM, Fredrik Jansson
wrote:
> I actually got a bit further with a secp256r1 server certificate, I
> also changed the server certificate version fro
25 matches
Mail list logo
