I noted there is a typo at "rsa_pkcs1_sha5256".
Fix this typo, SSL_CTX_set1_sigalgs_list works as expected.
Jared Huang 於 2022年9月20日 週二 下午5:34寫道：
> Hello,
>
>
>
> I’m using SSL_CTX_set1_sigalgs_list to set my favorite signature algorithm.
>
> But there is more a
Hello,
I’m using SSL_CTX_set1_sigalgs_list to set my favorite signature algorithm.
But there is more algorithm listed on client hello message than I desired.
I defined a list
#define TLS_PREFER_SIGNATURE"rsa_pss_rsae_sha256:" \
"rsa_
Hi,
Am Dienstag, 26. November 2019, 09:11:15 CET schrieb Rohit Kaushal:
> //enhancement, not working
>
> if(SSL_CTX_set1_curves(myCtx, "P-521:P-384:P-256", 3)) != 1))
>
> return;
>
>
>
> The API returns 0 (suggesting no error), but pcap shows no change, i.e.
> still shows the std. 13
able to trim the EC
> Supported Groups in the Client Hello with a TLS-ECDHE cipher using the APIs
> described in the OpenSSL v1.0.2 manpage for SSL_CTX_set1_curves()
> <https://www.openssl.org/docs/man1.0.2/man3/SSL_CTX_set1_curves.html>
>
>
>
> My shared objects are built
Hi,
I would like to ask if anyone here has actually been able to trim the EC
Supported Groups in the Client Hello with a TLS-ECDHE cipher using the APIs
described in the OpenSSL v1.0.2 manpage for SSL_CTX_set1_curves()
<https://www.openssl.org/docs/man1.0.2/man3/SSL_CTX_set1_curves.html>
On 15/11/2019 22:03, Phil Neumiller wrote:
>
> TLS 1.3 doesn't use EC point formats right? I don't know why they are in my
> TLS 1.3 client hello.
No, its not used in TLSv1.3 but is used in TLSv1.2 or below. A
ClientHello is sent before version negotiation takes place so you don't
TLS 1.3 doesn't use EC point formats right? I don't know why they are in my
TLS 1.3 client hello.
Extension: ec_point_formats (len=4)
Type: ec_point_formats (11)
Length: 4
EC point formats Length: 3
Elliptic curves point formats (3)
EC point format: uncompressed (0
On Tuesday, 12 November 2019 21:22:51 CET, Benjamin Kaduk via openssl-users
wrote:
On Tue, Nov 12, 2019 at 01:13:49PM -0700, Phil Neumiller wrote:
Thanks for all the useful device. I was able to get the server to accept
this client hello message.
If you're willing/able to share, it can
On Tue, Nov 12, 2019 at 03:08:19PM -0700, Phil Neumiller wrote:
> I find the comment below about TLS 1.3 troubling.
[...]
> */*
> * TODO(TLS1.3): These APIs cannot set TLSv1.3 sig algs so we just test
> it
> * for TLSv1.2 for now until we add a new API.
> */*
>
I find the comment below about TLS 1.3 troubling.
static int test_set_sigalgs(int idx)
{
SSL_CTX *cctx = NULL, *sctx = NULL;
SSL *clientssl = NULL, *serverssl = NULL;
int testresult = 0;
const sigalgs_list *curr;
int testctx;
/* Should never happen */
if
On Tue, Nov 12, 2019 at 01:13:49PM -0700, Phil Neumiller wrote:
> Thanks for all the useful device. I was able to get the server to accept
> this client hello message.
If you're willing/able to share, it can be useful for us to know what products
are buggy in that they don't implement exte
Thanks for all the useful device. I was able to get the server to accept
this client hello message.
TLSv1.3 Record Layer: Handshake Protocol: Client Hello
Content Type: Handshake (22)
Version: TLS 1.2 (0x0303)
Length: 257
Handshake Protocol: Client Hello
Handshake Type
On 11/11/2019 20:51, Phil Neumiller wrote:
> Extension: ec_point_formats (len=4)
> Type: ec_point_formats (11)
> Length: 4
> EC point formats Length: 3
> Elliptic curves point formats (3)
> EC point format: uncompressed (0)
> EC point
On 11/11/2019 21:09, Phil Neumiller wrote:
> The hardware wants to see a client hello like the following:
By this do you imply that if you give it additional extensions it fails?
That is a highly non-compliant implementation!!
Matt
On 11/11/2019 22:12, Michael Wojcik wrote:
> -Original Message-
>> From: openssl-users [mailto:openssl-users-boun...@openssl.org] On Behalf Of
>> Phil Neumiller
>> Sent: Monday, November 11, 2019 15:57
>>
>> Code: SSL_CTX_set_options(ctx, !SSL_OP_ALL);
>
> That's just a verbose way of
-Original Message-
> From: openssl-users [mailto:openssl-users-boun...@openssl.org] On Behalf Of
> Phil Neumiller
> Sent: Monday, November 11, 2019 15:57
>
> Code: SSL_CTX_set_options(ctx, !SSL_OP_ALL);
That's just a verbose way of saying SSL_CTX_set_options(ctx, 0).
Perhaps you meant
The hardware wants to see a client hello like the following:
Handshake Protocol: Client Hello
Handshake Type: Client Hello (1)
Length: 253
Version: TLS 1.2 (0x0303)
Random: 00010002000400090012…
GMT Unix Time: Dec 31, 1969 17:00:00.0 MST
Code: SSL_CTX_set_options(ctx, !SSL_OP_ALL);
-
Phillip Neumiller
Platform Engineering
Directstream, LLC
--
Sent from: http://openssl.6102.n7.nabble.com/OpenSSL-User-f3.html
By doing the following in my code:
I was able to get the Client Hello Extensions down to.
Handshake Protocol: Client Hello
Handshake Type: Client Hello (1)
Length: 365
Version: TLS 1.2 (0x0303)
Random: 19ff8a9231e83985887f5e45f2c9b243f0ccaa955beb1f03…
Session ID Length: 32
On 11/11/2019 19:43, Benjamin Kaduk via openssl-users wrote:
> On Mon, Nov 11, 2019 at 12:32:22PM -0700, Phil Neumiller wrote:
>> I am speaking TLS 1.3 with openssl to a hardware device that I can't change.
>> I need the client hello header to only support certain extensi
On Mon, Nov 11, 2019 at 12:32:22PM -0700, Phil Neumiller wrote:
> I am speaking TLS 1.3 with openssl to a hardware device that I can't change.
> I need the client hello header to only support certain extensions, yet I
> see no way in the SSL API to remove the default extensions in th
I am speaking TLS 1.3 with openssl to a hardware device that I can't change.
I need the client hello header to only support certain extensions, yet I
see no way in the SSL API to remove the default extensions in the TLS 1.3
client hello. Can I clear them all and just add the ones I want? What
Hi all,
The problem was an expired self-generated CA certificate. Now everything
works fine.
Br,
Harri
On 12.04.2019 20:20, Harri T. wrote:
Hi!
I'm trying to get LDAP STARTTLS working. What does "SSL_connect:error in SSLv3/TLS
write client hello → write:errno=0" mean?
Harri
Hi!
I'm trying to get LDAP STARTTLS working. What does "SSL_connect:error in
SSLv3/TLS write client hello → write:errno=0" mean?
Harri
root@ldap2:~# echo | openssl s_client -connect ldap2.mydomain.com:389
-showcerts -state -CAfile /etc/ssl/certs/ldap2_cacert.pem
CONNECTE
Hi All,
I am looking for an option in "openssl.cnf" file to control the signature
algorithms supported by an OpenSSL based TLS client application which it
lists in the "Client Hello" message and also the signature algorithm used
for signing the Client "Certif
I tried to modify " tls12_sigalgs" list under t1_lib.c in OpenSSL 1.0.2x
version to restrict a bunch of signature algorithms from being proposed during
Client hello message.
That did work.
Thanks.
Srivalli
On 6/19/18, 5:36 AM, "openssl-users on behalf of murugesh pitchaiah&quo
On 19/06/18 07:16, Devang Kubavat wrote:
> Hi,
>
>
>
> I want to disable the SHA1 hash algorithm in Extension: signature
> algorithm client hello message.
>
>
>
> I have used
>
> /* the signature algorithms list */
>
> constchars
i,
>
> I want to disable the SHA1 hash algorithm in Extension: signature algorithm
> client hello message.
>
> [cid:image003.jpg@01D407C3.1A227530]
>
> I have used
> /* the signature algorithms list */
> const char signAlgo[] = "RSA+SHA256";
>
Hi,
I want to disable the SHA1 hash algorithm in Extension: signature algorithm
client hello message.
[cid:image003.jpg@01D407C3.1A227530]
I have used
/* the signature algorithms list */
const char signAlgo[] = "RSA+SHA256";
(void)SSL_CTX_set1_client_sigalg
Hi Folks,
I'm working on an issue where something seems to be going wrong with our
internal state after a while, and one of our sessions will have suddenly lost
its SessionTicket during the Client Hello.
To debug the issue, I'm wondering if someone can point me to the right internal
variable
To: openssl-users@openssl.org
Subject: Re: [openssl-users] parse tlsext error in response to client hello
On 25/01/16 20:02, Wieck, Owen wrote:
> Dear all --
>
> Trying to debug a failing TLS negotiation. Is the following (possibly
> erroneous) "supported point formats extension"
ete "SSL record" of the client hello taken from
a packet capture:
16 03 01 00 5c 01 00 00 58 03 01 56 a6 52 fa a0
0010 7e e3 1d 40 16 89 dd 23 2a 92 dd b5 77 c5 d3 19
0020 10 82 07 9a 4f de 54 1e 69 c7 c4 00 00 1e 00 2f
0030 00 35 00 04 00 05 00 09 00 0a 00 03 00 08 c0 13
00
ete "SSL record" of the client hello taken from
a packet capture:
16 03 01 00 5c 01 00 00 58 03 01 56 a6 52 fa a0
0010 7e e3 1d 40 16 89 dd 23 2a 92 dd b5 77 c5 d3 19
0020 10 82 07 9a 4f de 54 1e 69 c7 c4 00 00 1e 00 2f
0030 00 35 00 04 00 05 00 09 00 0a 00 03 00 08 c0 13
00
ontain the value 0
> (uncompressed) as one of the items in the list of point formats."
>
> For reference, here is the complete "SSL record" of the client hello taken
> from a packet capture:
>
> 16 03 01 00 5c 01 00 00 58 03 01 56 a6 52 fa a0
> 0010 7
s_client -connect github.com:443
>
> The trace file you attached, which claims to go github.com:443,
> did send a Client Hello. However the reply is a plain text
> "400 Bad Request". It looks like you connected to port
m running a debian testing with all the updates
> available as of today, and libssl used is v1.0.2. If I execute:
>
> > openssl s_client -connect github.com:443
The trace file you attached, which claims to go github.com:443,
did send a Client Hello. However the reply is a plain tex
Hi all,
I have been searching for some time for a solution and I can not
manage to
solve my problem. I have a computer that can not connect to some sites, e.g.
github, by using openssl. I am running a debian testing with all the updates
available as of today, and libssl used is
Hi all,
I have been searching for some time for a solution and I can not
manage to
solve my problem. I have a computer that can not connect to some sites, e.g.
github, by using openssl. I am running a debian testing with all the updates
available as of today, and libssl used is
Hi,
Is it possible to make s_client give more detail about the client
hello it sends. A break down covering the RFC structure would be
useful.
struct {
ProtocolVersion client_version;
Random random;
SessionID session_id;
CipherSuite cipher_suites2
Took me a while to see, but the difference is in the last line of the client
hello. Your working example has MD5+RSA listed as a TLS 1.2 signature pair
whereas first doesn't.
0302 SHA-224 DSA
0303 SHA-224 ECDSA
0201 SHA-1 RSA
0202 SHA-1 DSA
0203 SHA-1 ECDSA
000F TLS_DH_RSA_WITH_DES_CBC_SHA
0101
On Wed, Nov 12, 2014, Tristan Hill wrote:
Hi,
Is it possible to make s_client give more detail about the client
hello it sends. A break down covering the RFC structure would be
useful.
struct {
ProtocolVersion client_version;
Random random
On 28 Oct 2014, at 1:30 PM, Florian Weimer f...@deneb.enyo.de wrote:
* Graham Leggett:
I have a need to parse the first incoming hello packet on an
incoming TLS connection and based on the presence (or absence) of
the SNI header, choose to pass the connection through to another
server
* Graham Leggett:
Is there a way to know whether the initial handshake has arrived fully?
I think you can abort the handshake from within the server name
callback with a suitable return value, so this does not really matter.
You just have to make sure the alert is never sent to the client, and
Hi all,
I have a need to parse the first incoming hello packet on an incoming TLS
connection and based on the presence (or absence) of the SNI header, choose to
pass the connection through to another server.
What openssl functions should I be looking at to do this?
Regards,
Graham
--
alpha_one_x86 alpha_one_...@first-world.info
Main developer of Ultracopier, Esourcing and server management
IT, OS, technologies, security and business department
---BeginMessage---
Hello,
I have some question:
http://h71000.www7.hp.com/doc/83final/ba554_90007/ch04s03.html
What part
Hello,
I have some question:
http://h71000.www7.hp.com/doc/83final/ba554_90007/ch04s03.html
What part is global, what part need be do by connexion?
On that's:
https://github.com/alphaonex86/CatchChallenger/blob/master/tools/epoll-with-buffer/main.cpp
I have edited it to try do simple echo server
Hello OpenSSL gurus,
I found in my sendmail-8.14.7/Fedora-18-i386 queue undelivered mails,
log say 'TLS handshake failed', and when I captured traffic between
mine and destination mailserver, I got result as in attached text export
from wireshark.
And when I tried:
openssl s_client -starttls
On Thu, Apr 03, 2014 at 01:18:13PM +0200, Frantisek Hanzlik wrote:
Hello OpenSSL gurus,
I found in my sendmail-8.14.7/Fedora-18-i386 queue undelivered mails,
log say 'TLS handshake failed', and when I captured traffic between
mine and destination mailserver, I got result as in attached text
Viktor Dukhovni wrote:
On Thu, Apr 03, 2014 at 01:18:13PM +0200, Frantisek Hanzlik wrote:
Hello OpenSSL gurus,
I found in my sendmail-8.14.7/Fedora-18-i386 queue undelivered mails,
log say 'TLS handshake failed', and when I captured traffic between
mine and destination mailserver, I got
Hello OpenSSL gurus,
I found in my sendmail-8.14.7/Fedora-18-i386 queue undelivered mails,
log say 'TLS handshake failed', and when I captured traffic between
mine and destination mailserver, I got result as in attached text export
from wireshark.
And when I tried:
openssl s_client -starttls
solved. libcurl (which I used for soap server) linked openssl version from
the system, not from project
--
View this message in context:
http://openssl.6102.n7.nabble.com/CentOS-5-openssl1-0-1e-SSL-accept-error-in-SSLv2-v3-read-client-hello-A-tp46479p46545.html
Sent from the OpenSSL - User
Hi,
I use standard scheme to send/receive SOAP requests over TLS. On Windows it
works good, server receive request from client, it handles correctly. On
Linux I have the following error:
SSL_accept:error in SSLv2/v3 read client hello A
In the 'verify callback' which I've set
as
TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256 [...but] Client Hello Message
[also has] TLS_ECDH_RSA_WITH_AES_128_CBC_SHA256
Same question (with same mistake) asked by allegedly different person
Fri and answered. Please read that.
__
OpenSSL Project
From: owner-openssl-us...@openssl.org On Behalf Of Tanmoy Sinha
Sent: Friday, 28 June, 2013 04:29
I am using a client application program which uses OpenSSL version
1.0.0h. I configured TLSv1.2 and I have set the cipher suite only as
TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256 [...but] Client Hello
, is that in Client Hello Message there
are 2 advertised ciphers suites. The first one
is TLS_ECDH_RSA_WITH_AES_128_CBC_SHA256 and second cipher suite
is TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256 (i.e. the one we requested),
although I've set only one cipher suite.
Moreover, my server application
, is that in Client Hello Message there
are 2 advertised ciphers suites. The first one
is TLS_ECDH_RSA_WITH_AES_128_CBC_SHA256 and second cipher suite
is TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256 (i.e. the one we requested),
although I've set only one cipher suite.
Moreover, my server application
-AES128-SHA256)
using the API SSL_CTX_set_cipher_list().
I think you're mistaken about 1.0.0h, unless it's a patched version.
TLSv1.1 and 1.2 protocols, and the 1.2-specific suites (SHA-2 and GCM),
were added only in 1.0.1.
But what I find in packet capture, is that in Client Hello Message
On Fri, Jun 28, 2013, Dave Thompson wrote:
1.0.1c and I believe earlier but not tested had several bugs
in selecting kECDH and TLSv1.2 ciphers fixed in 1.0.1e.
(Also kDH, but those aren't implemented anyway.)
Actually fixed DH is implemented now.
Steve.
--
Dr Stephen N. Henson. OpenSSL
Thanks for the reply. Using a lower version of TLS solved it for us.
//Toland (^_^x)
On May 30, 2013, at 10:29 PM, Dave Thompson dthomp...@prinpay.com wrote:
From: owner-openssl-us...@openssl.org On Behalf Of Toland Hon
Sent: Thursday, 30 May, 2013 22:22
I'm on Mac running OS X 10.8.3 and
changes can be done
on server end to get the required cipher ?
I have Linphone at app end, openssl version 1.0.0
And SIP Server | openssl 1.0.1c.
--
View this message in context:
http://openssl.6102.n7.nabble.com/Restricting-ciphers-list-to-RSA-only-in-Client-Hello-tp28933p45378.html
Sent from
From: owner-openssl-us...@openssl.org On Behalf Of Toland Hon
Sent: Thursday, 30 May, 2013 22:22
I'm on Mac running OS X 10.8.3 and have 2 versions of openssl installed:
* Default: OpenSSL 0.9.8r 8 Feb 2011
* Homebrew: OpenSSL 1.0.1e 11 Feb 2013
My most recent version of ruby
Hi All,
I would like to reject if the client hello doesn't contain
secure renegotiation info(RFC 5746). I could close the ssl connection after
it established. As per the RFC 5746 section 4.3 server shall terminate the
connection immediately
upon failure to negotiate the use of secure
wow this is pretty awesome you should give it a look
http://www.finance15dynews.net/biz/?read=9799495
__
OpenSSL Project http://www.openssl.org
User Support Mailing List
On 15/04/12 23:33, Dr. Stephen Henson wrote:
On Sun, Apr 15, 2012, Jeffrey Walton wrote:
On Sun, Apr 15, 2012 at 12:01 PM,toredhiddenu...@tormail.net wrote:
Hello guyz and cryptobrains! :P
One of the main disadvantages of EC on openssl seems to be the
inability
to create arbitrary-sized
On 17/04/12 06:57, toredhiddenu...@tormail.net wrote:
The library only supports Fp and F2^m custom curves. The easiest way to
construct a custom curve is by using one of:
EC_GROUP *EC_GROUP_new_curve_GFp(const BIGNUM *p, const BIGNUM *a, const
BIGNUM *b, BN_CTX *ctx);
EC_GROUP
On 15/04/12 23:33, Dr. Stephen Henson wrote:
On Sun, Apr 15, 2012, Jeffrey Walton wrote:
On Sun, Apr 15, 2012 at 12:01 PM,toredhiddenu...@tormail.net wrote:
Hello guyz and cryptobrains! :P
One of the main disadvantages of EC on openssl seems to be the inability
to create arbitrary-sized
Hello guyz and cryptobrains! :P
One of the main disadvantages of EC on openssl seems to be the inability
to create arbitrary-sized keys and advantage for RSA: you can create 32768
bit RSA key but... not greater than 521 bits on ECC.
Will this continue to be a disadvantage or can 32768 RSA key
On Sun, Apr 15, 2012 at 12:01 PM, toredhiddenu...@tormail.net wrote:
Hello guyz and cryptobrains! :P
One of the main disadvantages of EC on openssl seems to be the inability
to create arbitrary-sized keys and advantage for RSA: you can create 32768
bit RSA key but... not greater than 521
On 15/04/12 17:01, toredhiddenu...@tormail.net wrote:
Hello guyz and cryptobrains! :P
One of the main disadvantages of EC on openssl seems to be the inability
to create arbitrary-sized keys and advantage for RSA: you can create 32768
bit RSA key but... not greater than 521 bits on ECC
On Sun, Apr 15, 2012, Jeffrey Walton wrote:
On Sun, Apr 15, 2012 at 12:01 PM, toredhiddenu...@tormail.net wrote:
Hello guyz and cryptobrains! :P
One of the main disadvantages of EC on openssl seems to be the inability
to create arbitrary-sized keys and advantage for RSA: you can create
On Sun, Apr 15, 2012, Matt Caswell (fr...@baggins.org) wrote:
First of all there is nothing about the openssl EC library that
restricts the key length.
Well there is a limit on key sizes for public key algorithms to avoid their
use as a DoS attack. This limit is currently 661 bits for EC
On Sun, Apr 15, 2012 at 12:01 PM, toredhiddenu...@tormail.net wrote:
Hello guyz and cryptobrains! :P
One of the main disadvantages of EC on openssl seems to be the inability
to create arbitrary-sized keys and advantage for RSA: you can create
32768
bit RSA key but... not greater than 521
I've just started using openssl, and have been having some problems with
valgrind. Here's my distilled test program:
#include openssl-1.0.0e/include/openssl/hmac.h
#include openssl-1.0.0e/include/openssl/evp.h
#include string.h
char key[20] = { 0 };
int
main()
{
HMAC_CTX * context;
#include openssl-1.0.0e/include/openssl/hmac.h
#include openssl-1.0.0e/include/openssl/evp.h
#include string.h
char key[20] = { 0 };
int
main()
{
HMAC_CTX * context;
context = (HMAC_CTX *) malloc(sizeof(*context));
Do you need to malloc the context (a pointer) ?
I
Jonas Schnelli
jonas.schne...@include7.ch writes:
#include openssl-1.0.0e/include/openssl/hmac.h
#include openssl-1.0.0e/include/openssl/evp.h
#include string.h
char key[20] = { 0 };
int
main()
{
HMAC_CTX * context;
context = (HMAC_CTX *) malloc(sizeof(*context));
Do you
On 11/15/2011 11:39 AM, Henrik Grindal Bakken wrote:
Jonas Schnelli
jonas.schne...@include7.ch writes:
#includeopenssl-1.0.0e/include/openssl/hmac.h
#includeopenssl-1.0.0e/include/openssl/evp.h
#includestring.h
char key[20] = { 0 };
int
main()
{
HMAC_CTX * context;
context =
From: Jakob Bohm [mailto:jb-open...@wisemo.com]
Sent: Tuesday, November 15, 2011 2:28 PM
On 11/15/2011 11:39 AM, Henrik Grindal Bakken wrote:
Jonas Schnelli
jonas.schne...@include7.ch writes:
#includeopenssl-1.0.0e/include/openssl/hmac.h
#includeopenssl-1.0.0e/include/openssl/evp.h
it is really best place for us
i had try , it is truth and service is very good
fast ship and best quality
hope you can try too
here is : www.bestsker.com
enjoy yourself
On Mon June 20 2011, Alban Diquet wrote:
Hi all,
I've encountered a strange issue. It might not be related to OpenSSL itself,
but maybe it is.
When sending a Client Hello message that's larger than 270 bytes (not sure
what the exact limit is, 255 maybe?), lots of servers on the internet
On Tue, Jun 21, 2011 at 05:43:57AM -0500, Michael S. Zick wrote:
I've encountered a strange issue. It might not be related to OpenSSL itself,
but maybe it is.
When sending a Client Hello message that's larger than 270 bytes (not sure
what the exact limit is, 255 maybe?), lots
...@morganstanley.com
On Tue, Jun 21, 2011 at 05:43:57AM -0500, Michael S. Zick wrote:
I've encountered a strange issue. It might not be related to OpenSSL
itself,
but maybe it is.
When sending a Client Hello message that's larger than 270 bytes (not
sure
what the exact limit is, 255 maybe?), lots
sending a Client Hello message that's larger than 270
bytes (not sure
what the exact limit is, 255 maybe?), lots of servers on the
internet don't
send back any Server Hello, but keep the connection open, so
my client ends
up returning a timeout.
It's really
Hi all,
I've encountered a strange issue. It might not be related to OpenSSL itself,
but maybe it is.
When sending a Client Hello message that's larger than 270 bytes (not sure
what the exact limit is, 255 maybe?), lots of servers on the internet don't
send back any Server Hello, but keep
by this application in Client Hello
to those with only RSA key exchange.
Is there a way to configure it in OpenSSL?
I tried to compile the source code with SSL_DEFAULT_CIPHER_LIST
set to RSA:!aNULL:!eNULL:+RC4:@STRENGTH in ssl.h.
!aNULL after (only) RSA is a no-op.
When I run
Hi All,
I have built an SIP test application using openssl. I am trying to restrict
the ciphers sent by this application in Client Hello to those with only RSA
key exchange.
Is there a way to configure it in OpenSSL?
I tried to compile the source code with SSL_DEFAULT_CIPHER_LIST set to
RSA
Hi All,
I have built an SIP test application using openssl. I am trying to restrict
the ciphers sent by this application in Client Hello to those with only RSA key
exchange.
Is there a way to configure it in OpenSSL?
I tried to compile the source code with SSL_DEFAULT_CIPHER_LIST
be helpful.
Thanks and Regards,
Gauri
On Tue, May 3, 2011 at 10:42 AM, derleader mail derlea...@abv.bg wrote:
Hi All,
I have built an SIP test application using openssl. I am trying to restrict
the ciphers sent by this application in Client Hello to those with only RSA
key exchange
From: owner-openssl-us...@openssl.org On Behalf Of Gauri Kshirsagar
Sent: Tuesday, 03 May, 2011 05:37
I have built an SIP test application using openssl. I am trying
to restrict the ciphers sent by this application in Client Hello
to those with only RSA key exchange
Dave may be right about there being no direct evidence for a read.
However I have since looked at the code the error is coming from and the error is being
reported at the time the SSL context is being interpreted, which doesn't mean the initial
loading of the SSL context wasn't error free as
-users@openssl.org
Subject: Re: Hello!
ASN.1 encoding will require much more than a simple sprintf.
If your resulting string is expected to be encoded in ASN.1, then there
may be a problem there.
Pierre
Le 04/10/2010 22:02, irivas a écrit :
To further clarify:
The error is a result of a call
From: owner-openssl-us...@openssl.org On Behalf Of Jeremy Hunt
Sent: Monday, 04 October, 2010 19:08
You are reading files, see inline for discussion.
On 5/10/2010 7:36 AM, irivas wrote:
SSL_CTX_load_verify_locations(ctx,NULL,foldername);//ctx
Hello everyone!
My name's Irving and I'm new to openssl.
I'm having an issue and I hope I can get help here.
I have a tiny software written to communicate with an http server; on a
Solaris system it works alright, but on an OpenVMS system I'm getting these
errors:
545318540:error:0D07809F:asn1
On Mon October 4 2010, irivas wrote:
Hello everyone!
My name's Irving and I'm new to openssl.
I'm having an issue and I hope I can get help here.
I have a tiny software written to communicate with an http server; on a
Solaris system it works alright, but on an OpenVMS system I'm getting
I have a tiny software written to communicate with an http server; on a
Solaris system it works alright, but on an OpenVMS system I'm getting
these
errors:
545318540:error:0D07809F:asn1 encoding
routines:ASN1_ITEM_EX_D2I:unexpected
eoc:TASN_DEC:337:Type=X509_ALGOR
I do not know anything about OpenVMS and Solaris,
BUT big endian / little endian and improper use of htons in YOUR software
could explain many things.
You should check also \r and \r \n issue, even if not reading any file,
because it may be in cause in fprintf(fd, \n);
\n being expanded
-
From: owner-openssl-us...@openssl.org
[mailto:owner-openssl-us...@openssl.org] On Behalf Of Pierre DELAAGE
Sent: Monday, October 04, 2010 3:25 PM
To: openssl-users@openssl.org
Subject: Re: Hello!
I do not know anything about OpenVMS and Solaris,
BUT big endian / little endian and improper use of htons
Of Pierre DELAAGE
Sent: Monday, October 04, 2010 3:25 PM
To: openssl-users@openssl.org
Subject: Re: Hello!
I do not know anything about OpenVMS and Solaris,
BUT big endian / little endian and improper use of htons in YOUR software
could explain many things.
You should check also \r and \r \n issue, even
] On Behalf Of Pierre DELAAGE
Sent: Monday, October 04, 2010 4:15 PM
To: openssl-users@openssl.org
Subject: Re: Hello!
ASN.1 encoding will require much more than a simple sprintf.
If your resulting string is expected to be encoded in ASN.1, then there
may be a problem there.
Pierre
Le 04/10/2010 22
From: owner-openssl-us...@openssl.org On Behalf Of irivas
Sent: Monday, 04 October, 2010 16:36
(I changed the subject to be more descriptive.)
I don't even know where those errors come from. As I said
before, the same code under Solaris runs alright.
I'm only connecting to a regular
This time my question isn't out of necessity, but rather curiosity.
I've been playing around with calculating the Session Key, and the IV for an
SSL connection for a man-in-the-middle type proxy, and finally stumbled upon
the EVP_CIPHER_ctx module. Inside of this struct there are two data
1 - 100 of 197 matches
Mail list logo
