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 curves.
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
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: uncom
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 c
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.
> */*
> SSL_CTX_set_ma
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 (!TEST_size_t_
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 impl
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 f
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 s
-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 SSL
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 ex
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
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?
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?
Ha
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
CON
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 "CertificateVe
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
PM
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&q
UST contain 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
> 001
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 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
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 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
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 v1.0.2
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 v1.0.2
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;
>
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
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_suites
* 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
On 28 Oct 2014, at 1:30 PM, Florian Weimer 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 a
* 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.
I think you'll need to work with BIOs to make a co
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
Main developer of Ultracopier, Esourcing and server management
IT, OS, technologies, security and business department
--- Begin Message ---
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
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 s
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
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
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
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
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
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.
>
>
> __
[...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
, 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 applic
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. Ope
A256 (i.e. ECDH-ECDSA-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 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 applic
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 the
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 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 have 2 versions
>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 (1.9
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 s
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 Listopenssl
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 *EC_GROUP_n
> 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, wrote:
>>>> Hello guyz and cryptobrains! :P
>>>>
>>>> One of the main disadvantages of EC on openssl s
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, 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
> On Sun, Apr 15, 2012 at 12:01 PM, 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
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
On Sun, Apr 15, 2012, Jeffrey Walton wrote:
> On Sun, Apr 15, 2012 at 12:01 PM, 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 c
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.
Will
On Sun, Apr 15, 2012 at 12:01 PM, 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 o
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 be
> 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
> > writes:
> >
> >>> #include
> >>> #include
> >>> #include
> >>>
> >>> char key[20] = { 0 };
> >>>
> >>> int
> >>> main()
>
On 11/15/2011 11:39 AM, Henrik Grindal Bakken wrote:
Jonas Schnelli
writes:
#include
#include
#include
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 don't think so.
Remove
Jonas Schnelli
writes:
>> #include
>> #include
>> #include
>>
>> 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 don't think so.
> Remove the line?
T
>
>
>
> #include
> #include
> #include
>
> 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 don't think so.
Remove the line?
>
>HMAC_CTX_init(context);
>
I've just started using openssl, and have been having some problems with
valgrind. Here's my distilled test program:
#include
#include
#include
char key[20] = { 0 };
int
main()
{
HMAC_CTX * context;
context = (HMAC_CTX *) malloc(sizeof(*context));
HMAC_CTX_init(context);
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
now I want to
> know what's going on.
>
> > > 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 He
> 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
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
> > wh
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
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 Hell
rs 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:!aNULL:!eNULL:+RC4:@STRENGTH"
> 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 R
rom my end would be helpful.
Thanks and Regards,
Gauri
On Tue, May 3, 2011 at 10:42 AM, derleader mail 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
>
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
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
&quo
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
> 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);//
tober 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:02, irivas a écrit :
To further clarify:
> 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
enssl.org
[mailto:owner-openssl-us...@openssl.org] 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 pr
g] 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 in YOUR software
could explain many things.
You should check also \r
riginal Message-
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
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 d
> 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
> 545318540:error:0D0
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 work
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
1 - 100 of 201 matches
Mail list logo
