Re: Non-heap based structures

[J Decker]

looks like https://linux.die.net/man/3/evp_md_ctx_init initializes a
structure that's allocated already.  Yes it could be on the stack, or
static...
(instead of _new)

On Wed, Jul 27, 2022 at 1:42 AM Philip Prindeville <
philipp_s...@redfish-solutions.com> wrote:

> Hi,
>
> I suspect I already know the answer, but... is there a way to have a
> non-heap based structure like EVP_MD_CTX?
>
> If I don't want to have one be malloc'd (or OPENSSL_zalloc'd as the case
> may be), I can't have one be a stack variable or static, can I?
>
> I ask because I'm trying to replace some existing code that has no path to
> handle out-of-memory exceptions if EVP_MD_CTX_create() ever returns NULL...
>
> I guess the point of crypto/evp/evp_local.h is to completely hide details
> of the structure, including its size... so the answer to the original
> question is probably "no".  But I just wanted to make sure.
>
> Thanks,
>
> -Philip
>
>

Re: Differently named symbols between OpenSSL and RFC

[J Decker]

On Fri, Nov 29, 2019 at 10:16 AM Viktor Dukhovni 
wrote:

> On Thu, Nov 28, 2019 at 04:31:38PM -0800, J Decker wrote:
>
> > from openssl/tls1.h 1.1.1b
> >
> > # define TLSEXT_TYPE_psk_kex_modes   45
>
> This was added in 1.1.1-dev.
>
> > pre_shared_key(41), psk_key_exchange_modes(45), are what the names
> should be
> > based on, and that OpenSSL's definition is also inaccurate
> >
> >  TLSEXT_TYPE_psk_kex_modes
> >  TLSEXT_TYPE_psk
> >
> > instead of 'pre_shared_key' and 'key_exchange_modes'
>
> The TLS RFCs do not define an API, they only define a wire protocol.
>
> Implementations are free to use whatever names they see fit for the
> various RFC
> code-points.  OpenSSL chose to abbreviate "key_exchange" to "kex" and
> "pre_shared_key" to "psk".  The LibreSSL maintainers are free to make
> their own
> choices.
>

Well; since they are the clone of the original, they're not exactly 'free'
to make choices; there are constraints issued by consumers of their
libraries (me) that they should be compatible.  So; Their argument for name
choice is 'RFC' , I thought 'understandable easily' but making it the same
as the RFC allows one to search for information on what that extension
might be.  Looking for 'psk' and 'kex' doesn't lead to related information
very well, which is an argument that OpenSSL should also provide alternate
names which align better with other information about such names...

I looked a while to find those symbols when I initially ran into this
issue; and psk just kept coming back to openssl headers/docs which
themselves don't give very good information about the block.



>
> --
> Viktor.
>

Differently named symbols between OpenSSL and RFC

[J Decker]

I made this issue on LibreSSL's github...
https://github.com/libressl-portable/portable/issues/537

It's about ...

TLSEXT_TYPE_psk_kex_modes:

from openssl/tls1.h 1.1.1b

# define TLSEXT_TYPE_psk_kex_modes   45

from libressl/2.9.2 tls1.h

#define TLSEXT_TYPE_psk_key_exchange_modes  45

They argue that the names they defined follow the RFC


https://tools.ietf.org/html/rfc8446#section-4.2



 pre_shared_key(41), psk_key_exchange_modes(45),

are what the names should be based on, and that OpenSSL's definition is
also inaccurate
TLSEXT_TYPE_psk_kex_modes
 TLSEXT_TYPE_psk
https://github.com/openssl/openssl/blob/master/include/openssl/tls1.h#L143-L147


instead of 'pre_shared_key' and 'key_exchange_modes'


(sorry, this looks kind of ragged, get what I'm sayin?)

Re: BIO in memory usage....

[J Decker]

On Sun, Jun 16, 2019 at 3:17 AM Tobias Wolf  wrote:

> I`d like to understand how a memory bio can be reseted with the internal
> read counter back to zero for further reusage.
>
>
>
> e.g.
>
> I want to try to read first der and then pem
>
>
>
> d2i_X509 
>
>
>
> and then:
>
>
>
> PEM_read_X509
> 
>
>
>
> Then the second call will fail because the bio has already read some
> bytes, when I call each function with a newly created bio it is working
> fine.
>
> I already tried with BIO_seek, BIO_tell (returns 0?!), BIO_reset.
>

After reset did you also refill it?

>
>

Re: Trying to use a ((constructor)) to force libcrypto.so into FIPS mode

[J Decker]

On Thu, Jun 6, 2019 at 2:34 PM Larry Jordan via openssl-users <
openssl-users@openssl.org> wrote:

> Re: openssl-1.0.2r
>
> Re: openssl-fips-2.0.16
>
> OS: Linux Mint 19.1 (Ubuntu)
>
>
>
> I have added a shared library initializer function to cryptlib.c to force
> OpenSSL into FIPS mode, without requiring a “module operator” to directly
> initiate (i.e. call FIPS_mode_set(1)).
>
>
>
> void __attribute__((constructor)) ForceFIPSModeOn()
>
> {
>
>FIPS_mode_set(1);
>
>FIPS_selftest_check();
>
> }
>
>
>
> The build fails shortly after creating the executable ‘fips_premain_dso’.
>
>
>
> fips.c(140): OpenSSL internal error, assertion failed: FATAL FIPS SELFTEST
> FAILURE
>
> Aborted (core dumped)
>

I'm gonna guess that this is calling a function before OpenSSL Is
initialized... did you also move your init code to a constructor?


>
>
> I traced the problem to a failed FIPS_check_incore_fingerprint call. The
> embedded signature appears uninitialized:
>
>
>
> Starting FIPS_selftest
> fips: 00 ff 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> imem: 33 53 e6 29 f6 eb df f3 d0 23 e9 7c 39 84 91 e0 3f 32 83 b2
>  failed FIPS_check_incore_fingerprint
>
>
>
> I am at a loss to explain what is happening. Is my initializer running
> before the embedded sig is loaded? Or is there another issue.
>
>
>
> If I remove the call to FIPS_selftest_check(), the link completes, but the
> selftest still fails, when it is initiated from the initializer. A “module
> operator” can still use the libcrypto.so services, because all subsequent
> selftests pass.
>
>
>
> How can I get my module initializer to pass the selftest?
>
>
>
> Sent from Mail  for
> Windows 10
>
>
>

Re: Building OpenSSL with Emscripten

[J Decker]

https://stackoverflow.com/questions/52327290/linking-openssl-with-webassembly

Looks very similar...

'target_link_libraries(mainTest crypto) after that it all worked without
warnings.'

On Mon, May 20, 2019 at 1:56 AM Richard Levitte  wrote:

> The issue isn't with any defined or not so defined macro, but most
> probably rather with how you're loading the library in the 3rd party
> code base.  Could it be that you're linking with libssl only?
>
> Cheers,
> Richard
>
> On Fri, 10 May 2019 22:29:36 +0200,
> Sunghyun Park wrote:
> >
> > Hi, all. Thanks for your help, I could finish compilation to the end.
> > However, athough I successfully compiled with _no-asm_ options, I found
> a problem when loading the
> > compiled library in the 3rd party code base.
> > When looking into the source code, the definition of some function seems
> to require a specific
> > preprocessor to be compiled.
> > (For example, PEM_write_bio_DSAPrivateKey needs '#define OPENSSL_FIPS'.)
> > I installed openssl-1.0.2r.tar.gz and only provided no-asm for
> configuration.
> > Am I missing some dependencies or necessary options?
> > The error I'm facing is as follows:
> >
> > error: undefined symbol: AES_ctr128_encrypt
> > warning: To disable errors for undefined symbols use `-s
> ERROR_ON_UNDEFINED_SYMBOLS=0`
> > error: undefined symbol: AES_set_encrypt_key
> > error: undefined symbol: BIO_ctrl
> > error: undefined symbol: BIO_free
> > error: undefined symbol: BIO_new
> > error: undefined symbol: BIO_s_mem
> > error: undefined symbol: BN_bn2bin
> > error: undefined symbol: BN_free
> > error: undefined symbol: BN_is_bit_set
> > error: undefined symbol: BN_new
> > error: undefined symbol: BN_num_bits
> > error: undefined symbol: BN_set_word
> > error: undefined symbol: CRYPTO_free
> > error: undefined symbol: CRYPTO_malloc
> > error: undefined symbol: DSA_free
> > error: undefined symbol: DSA_generate_key
> > error: undefined symbol: DSA_generate_parameters_ex
> > error: undefined symbol: DSA_new
> > error: undefined symbol: EC_KEY_free
> > error: undefined symbol: EC_KEY_generate_key
> > error: undefined symbol: EC_KEY_get0_group
> > error: undefined symbol: EC_KEY_get0_public_key
> > error: undefined symbol: EC_KEY_new_by_curve_name
> > error: undefined symbol: EC_KEY_set_asn1_flag
> > error: undefined symbol: EC_POINT_point2oct
> >
> > 
> >
> > Any advice would be a great help!
> > Thank you.
> >
> > On Thu, May 9, 2019 at 10:43 PM Dr Paul Dale 
> wrote:
> >
> > Configure with the _no-asm_ option.
> >
> > It will be a **lot** slower.
> >
> > Pauli
> > --
> > Dr Paul Dale | Cryptographer | Network Security & Encryption
> > Phone +61 7 3031 7217
> > Oracle Australia
> >
> > On 10 May 2019, at 3:33 pm, Sunghyun Park 
> wrote:
> >
> > Nice to meet you all :)
> >
> > I faced a problem while building assembly code in OpenSSL (e.g.,
> crypto/x86_64cpuid.s)
> > with Emscripten.
> > Since Emscripten does not support compilation for assembly code
> (As far as I know), I'm
> > wondering if there is any version of OpenSSL that does not
> require compiling assembly
> > code.
> > Or, if there is anyone who experienced the similar problem,
> please share your experience.
> >
> > Thank you!
> >
> > --
> > Best, Sung
> >
> > --
> > Best, Sung
> >
> >
> --
> Richard Levitte levi...@openssl.org
> OpenSSL Project http://www.openssl.org/~levitte/
>

Re: In-memory SSL_CTX_use_certificate_chain_file?

[J Decker]

On Sun, Mar 17, 2019 at 5:17 PM Felipe Gasper 
wrote:

>
>
> On Mar 17, 2019, at 7:55 PM, J Decker  wrote:
>
>
> On Sun, Mar 17, 2019 at 4:46 PM Felipe Gasper 
> wrote:
>
>> Buffer, not buffet. Silly autocorrect!
>>
>> -F
>>
>> > On Mar 17, 2019, at 7:21 PM, Felipe Gasper 
>> wrote:
>> >
>> > Hello,
>> >
>> > Is there any equivalent to SSL_CTX_use_certificate_chain_file for a PEM
>> buffet that’s already in memory?
>>
> SSL_CTX_use_certificate( ses->ctx, sk_X509_value( ses->cert->chain, 0 ) );
> ?
> SSL_CTX_add_extra_chain_cert( ses->ctx, sk_X509_value( ses->cert->chain, n
> ) );
>
>
> Yeah, but then I have to determine how many certs are in the bundle, parse
> it, etc. I was hoping to get a function that does all of that in one fell
> swoop like the ..._file() function.
>
> I mean, I guess I can copy/paste and tweak for now. Would a refactor in a
> PR be of interest?
>
>
that top of this takes the input, uses bio to parse into x509 stack, and
then uses the stack setting up the ctx...

https://github.com/d3x0r/SACK/blob/master/src/netlib/ssl_layer.c#L665-L753


> -FG
>
>
>

Re: In-memory SSL_CTX_use_certificate_chain_file?

[J Decker]

On Sun, Mar 17, 2019 at 4:46 PM Felipe Gasper 
wrote:

> Buffer, not buffet. Silly autocorrect!
>
> -F
>
> > On Mar 17, 2019, at 7:21 PM, Felipe Gasper 
> wrote:
> >
> > Hello,
> >
> > Is there any equivalent to SSL_CTX_use_certificate_chain_file for a PEM
> buffet that’s already in memory?
>
SSL_CTX_use_certificate( ses->ctx, sk_X509_value( ses->cert->chain, 0 ) );
?
SSL_CTX_add_extra_chain_cert( ses->ctx, sk_X509_value( ses->cert->chain, n
) );

and/or maybe

X509_STORE *store = SSL_CTX_get_cert_store( ses->ctx );
X509_STORE_add_cert( store, cert );

>
> > Thank you!
> >
> > -F
>
>

Re: [openssl-users] when should client stop calling SSL_read to get TLS1.3 session tickets after the close_notify?

[J Decker]

On Mon, Feb 18, 2019 at 2:18 PM Jakob Bohm via openssl-users <
openssl-users@openssl.org> wrote:

> On 17/02/2019 14:26, Matt Caswell wrote:
> > On 16/02/2019 05:04, Sam Roberts wrote:
> >> On Fri, Feb 15, 2019 at 3:35 PM Matt Caswell  wrote:
> >>> On 15/02/2019 20:32, Viktor Dukhovni wrote:
> > On Feb 15, 2019, at 12:11 PM, Sam Roberts 
> wrote:
>  OpenSSL could delay the actual shutdown until we're about to return
>  from the SSL_accept() that invoked the callback.  That is
> SSL_shutdown()
>  called from callbacks could be deferred until a more favourable time.
> >> In this case, it's an SSL_read() that invoked the callback, though
> >> probably not relevant.
> >>
> >> And actually, no deferal would be necessary, I looks to me that the
> >> info callback for handshake done is coming too early. Particularly,
> >> the writing of the NewSessionTickets into the BIO should occur before
> >> the info callback. I'll check later, but I'm pretty sure with TLS1.2
> >> the session tickets are written and then the HANDSHAKE_DONE info
> >> callback occurs, so the timing here is incompatible with TLS1.2.
> > In TLSv1.2 New session tickets are written as part of the handshake. In
> TLSv1.3
> > session tickets are sent after the handshake has completed. It sounds to
> me like
> > the info callback is doing the right thing.
> That seems to be a major theme in many reported OpenSSL 1.1.1
> problems.  It seems that you guys have gotten too hung up on how
> the TLS 1.3 RFC uses words like handshake differently than the
> TLS 1.2 RFC, rather than by the higher level semantics of what
> would be considered the API visible meta-operations.
>
>  From an API user perspective, the messages that are exchanged
> right after the RFC-handshake in order to complete the connection
> set up should be considered part of the API-handshake.
>
> This made little difference for the "change cipher spec" TLS 1.2
> record, but makes a lot more difference for TLS 1.3 where various
> things like certificate checks and session tickets fall into that
> gray area.
>
> Any opportunity to send data earlier than that should be handled
> in a way that doesn't break the API for applications that aren't
> doing so.
> >> Though the deferal mechanism might be there already. It looks like
> >> doing an SSL_write(); SSL_shutdown() in the info callback works fine,
> >> on the client side new ticket callbacks are fired by the SSL_read()
> >> before the SSL_read() sees the close_notify and returns 0. I haven't
> >> looked at the packet/API trace for this, because the tests all pass
> >> for this case, but I do see that in the javascript called from the
> >> HANDSHAKE_DONE callback, that calling .end("x") (write + shutdown)
> >> causes the client to get tickets, but .end() causes it to miss them
> >> because they are after close_notify.
> >>
> >>> Oh - right. I missed this detail. Calling SSL_shutdown() from inside a
> callback
> >>> is definitely a bad idea. Don't do that.
> >> The info callback, or ANY callbacks? What about the new ticket
> >> callback, for example? Is it expected that no SSL_ calls are made in
> >> ANY callbacks?
> > I wouldn't go that far. Callbacks occur during the processing of an IO
> > operation. Callbacks are generally expected to be small and quick. I
> wouldn't
> > call anything that might invoke a new IO operation from within a
> callback, so
> > SSL_read, SSL_write, SSL_do_handshake, SSL_shutdown etc.
> >
> Callbacks are often an opportunity for applications to detect
> violations of security policy.  It thus makes a lot of sense for
> callbacks to request that the connection is ended as soon as
> allowed by the risk of creating an attack side channel.
>
> Other OpenSSL callbacks represent the one place to do certain
> complex tasks, such as choosing among different certificates,
> checking against outside (networked!) revocation systems etc.>
>
>
All of that makes me question; so in migrating to 1.3, does the basic flow
change?

>
https://github.com/d3x0r/SACK/blob/master/src/netlib/ssl_layer.c#L178
 (handshake... hmm that's long tedious debug optioned code)

summary is pretty short...

 if (!SSL_is_init_finished(ses->ssl)) {r = SSL_do_handshake(ses->ssl); if(
r == 0 )/*error/incomplete */ else /* handle errors; usually WANT_READ;
 read for any control data pending, and send  data*/ } else return 2/1;

>
until is_init_finished which is handshake() returns 2 on the first
is_init_finished... and 1 after that; so the first callback does
certificate verification...

>
then kinda...

> onread() { /* recv got data */

> handshake();

>   -1 ; close

>0 - return wait for more data

>2 - verify handshaken certs

>1 - continue as normal.

> read data (if any) (post to app)

> read if any control data/send control data to remote

> }

>
and I could optionally? register verification callbacks and remove the == 2
check inline?



> Enjoy
>
> Jakob
> --
> Jakob Bohm, CIO, Partner, WiseMo 

Re: [openssl-users] Path Length Constraint ignored for Root and any self-issued certificate

[J Decker]

It was my interpretation that 0 pathlen on the root self signed meant
infinite.
The pathlen only applies on the certs between root and the leaf (which
obviously can be 0, and CA true or not, but bad form to say true I'd
imagine.)

On Mon, Oct 8, 2018 at 1:57 AM Peter Magnusson <
blaufish.public.em...@gmail.com> wrote:

> One more logic confusion in the OpenSSL Path Length Constraint check.
> Any Path Length Constraint set by Root (or any other Self-Issued
> Certificate) is ignored.
> Root cause appears to be !(x->ex_flags & EXFLAG_SI)=0 incorrectly
> applied to the checker (i.e. the checker and the calculation logic
> have been mixed up).
>
> https://github.com/blaufish/openssl-pathlen/tree/master/testcase_2
>
> openssl x509 -text -in root.pem | grep -a1 "X509v3 Basic"
> Certificate Sign, CRL Sign
> X509v3 Basic Constraints: critical
> CA:TRUE, pathlen:0
> openssl x509 -text -in evilca.pem | grep -a1 "X509v3 Basic"
> Certificate Sign, CRL Sign
> X509v3 Basic Constraints: critical
> CA:TRUE, pathlen:0
> openssl x509 -text -in evilserver.pem | grep -a1 "X509v3 Basic"
> X509v3 extensions:
> X509v3 Basic Constraints: critical
> CA:FALSE
> 
> openssl x509 -text -in root.pem | egrep -a1 "X509v3 .* Key Identifier"
> X509v3 extensions:
> X509v3 Subject Key Identifier:
> 49:39:72:82:78:39:E8:60:AD:17:79:83:DB:65:B8:5C:E6:A7:84:B5
> --
> --
> 49:39:72:82:78:39:E8:60:AD:17:79:83:DB:65:B8:5C:E6:A7:84:B5
> X509v3 Authority Key Identifier:
>
> keyid:49:39:72:82:78:39:E8:60:AD:17:79:83:DB:65:B8:5C:E6:A7:84:B5
> openssl x509 -text -in evilca.pem | grep -a1 "X509v3 .* Key Identifier"
> X509v3 extensions:
> X509v3 Subject Key Identifier:
> B6:B4:75:66:18:B5:D2:4F:57:10:53:93:4F:CD:51:71:A4:27:84:7C
> --
> --
> B6:B4:75:66:18:B5:D2:4F:57:10:53:93:4F:CD:51:71:A4:27:84:7C
> X509v3 Authority Key Identifier:
>
> keyid:49:39:72:82:78:39:E8:60:AD:17:79:83:DB:65:B8:5C:E6:A7:84:B5
> openssl x509 -text -in evilserver.pem | egrep -a1 "X509v3 .* Key
> Identifier"
> TLS Web Server Authentication
> X509v3 Subject Key Identifier:
> 03:C6:48:91:09:73:F5:DF:EF:B5:9D:A4:66:00:16:C3:E9:DB:99:EE
> --
> --
> 03:C6:48:91:09:73:F5:DF:EF:B5:9D:A4:66:00:16:C3:E9:DB:99:EE
> X509v3 Authority Key Identifier:
>
> keyid:B6:B4:75:66:18:B5:D2:4F:57:10:53:93:4F:CD:51:71:A4:27:84:7C
> 
> ../openssl-1.1.1/apps/openssl verify -show_chain -verbose -CAfile
> root.pem -untrusted evilca.pem evilserver.pem
> *** important variables ***
> *** check_chain_extensions:524 i=0
> *** check_chain_extensions:525 plen=0
> *** check_chain_extensions:526 x->ex_pathlen=-1
> *** if statement components ***
> *** check_chain_extensions:528 i > 1=0
> *** check_chain_extensions:529 !(x->ex_flags & EXFLAG_SI)=1
> *** check_chain_extensions:530 (x->ex_pathlen != -1)=0
> *** check_chain_extensions:531 (plen > (x->ex_pathlen +
> proxy_path_length + 1))=0
> *** important variables ***
> *** check_chain_extensions:524 i=1
> *** check_chain_extensions:525 plen=1
> *** check_chain_extensions:526 x->ex_pathlen=0
> *** if statement components ***
> *** check_chain_extensions:528 i > 1=0
> *** check_chain_extensions:529 !(x->ex_flags & EXFLAG_SI)=1
> *** check_chain_extensions:530 (x->ex_pathlen != -1)=1
> *** check_chain_extensions:531 (plen > (x->ex_pathlen +
> proxy_path_length + 1))=0
> *** important variables ***
> *** check_chain_extensions:524 i=2
> *** check_chain_extensions:525 plen=2
> *** check_chain_extensions:526 x->ex_pathlen=0
> *** if statement components ***
> *** check_chain_extensions:528 i > 1=1
> *** check_chain_extensions:529 !(x->ex_flags & EXFLAG_SI)=0
> *** check_chain_extensions:530 (x->ex_pathlen != -1)=1
> *** check_chain_extensions:531 (plen > (x->ex_pathlen +
> proxy_path_length + 1))=1
> evilserver.pem: OK
> Chain:
> depth=0: C = SE, ST = EvilServer, L = EvilServer, O = EvilServer, OU =
> EvilServer, CN = EvilServer (untrusted)
> depth=1: C = SE, ST = EvilCA, L = EvilCA, O = EvilCA, OU = EvilCA, CN
> = EvilCA (untrusted)
> depth=2: C = SE, ST = Root, L = Root, O = Root, OU = Root, CN = Root
> --
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
>
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] Using Windows system certficate store for server authentication

[J Decker]

On Fri, Sep 7, 2018 at 11:55 PM Juan Isoza  wrote:

>
> It's a good idea using openssl under windows (with new openssl 1.1.1, we
> will be able to use TLS 1.3 under Windows, from 7/2008 to 10/2016) instead
> internal windows crypto..
>
> But, by example, curl build for windows with openssl need a --insecure
> parameters or a custom root certificate file.
>
> What about using the Windows certificate store ?
>
Loading the windows cert store isn't very hard

https://github.com/d3x0r/SACK/blob/master/src/netlib/ssl_layer.c#L1037
But checking; I Guess that's just the code from that stack overflow.
basically verbatim.


>
> I found info at
>
> https://stackoverflow.com/questions/9507184/can-openssl-on-windows-use-the-system-certificate-store/15451831
>
https://stackoverflow.com/questions/9507184/can-openssl-on-windows-use-the-system-certificate-store/15451831


>
>
> There is some code in openssl (in engines\e_capi.c) which deal with
> Windows certificate store, but this seem not solve the problem
> --
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
>
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] passing CA bundle as buffer, instead of file path, to X509_STORE_CTX_ functions

[J Decker]

You can use a BIO_new( BIO_s_mem() ) to feed the memory through
BIO_writeand  PEM_read_bio_X509

something like ...
https://github.com/d3x0r/SACK/blob/master/src/netlib/ssl_layer.c#L780

On Tue, Sep 4, 2018 at 8:07 AM Eli Golosovsky 
wrote:

> Is there an option, in *OpenSSL 1.1.1*, to load a CA bundle from memory
> (buffer / string) instead of loading it from a file?
>
> From my experience, loading a CA bundle can be achieved by using the
> *X509_STORE_CTX_* functions, on an *X509_STORE_CTX* object, representing
> the certificate, and finalizing with *X509_verify_cert*. But I know of no
> way to load the CA bundle not from disk.
>
> Thanks in advance,
> Ilya Golosovsky
> --
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
>
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] How to prove a Certificate is Signed or not

[J Decker]

a root cert is the self signed cert.


On Thu, May 3, 2018 at 2:50 AM, morthalan 
wrote:

> But In my case, I do not have any root certificate. I have only one signed
> certificate (SignedCertificate.pem) and one certificate signing request
> (certReq.pem) . So when I use it as below
>
> openssl verify -CAfile SignedCertificate.pem SignedCertificate.pem
>
> I am getting error  "error 20 at 0 depth lookup:unable to get local issuer
> certificate".
> I believe it is for verifying certificate chain trust. Correct me if I am
> wrong. Is there anyway to manipulate it?
>
>
> Richard Levitte - VMS Whacker-2 wrote
> > openssl verify -CAfile your_ca_cert.pem SignedCertificate.pem
> >
> > Hope that helped
> >
> > Cheers,
> > Richard
> >
> > openssl-users mailing list
> > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
>
>
>
>
>
> --
> Sent from: http://openssl.6102.n7.nabble.com/OpenSSL-User-f3.html
> --
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
>
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] How to prove a Certificate is Signed or not

[J Decker]

Or using the javascript interface

https://www.npmjs.com/package/sack.vfs#interface

https://github.com/d3x0r/sack.vfs/blob/master/tests/tlsTest.js#L28

if( vfs.TLS.validate( {cert:signedCert3, chain:signedCert2+cert} ) )
console.log( "Chain is valid." );

On Thu, May 3, 2018 at 12:36 AM, J Decker <d3c...@gmail.com> wrote:

> https://github.com/d3x0r/sack.vfs/blob/master/src/tls_interface.cc#L1538
> this routine does cert validation but I don't thkn that's what you want
>
> this verified on a connection https://github.
> com/d3x0r/SACK/blob/master/src/netlib/ssl_layer.c#L274
>
> which boils down to
> SSL_get_peer_certificate ,  SSL_get_verify_result
>
> On Thu, May 3, 2018 at 12:06 AM, Anil kumar Reddy <
> morthalaanilre...@gmail.com> wrote:
>
>> Hi everyone,
>>
>> I am new to opennssl and now I am completely confused. Please help me out
>> to solve my issue.
>>
>> I have implemented a code to sign the given CSR certificate
>> (certReq.pem), then generate openssl signed Certificate
>> (SignedCertificate.pem) using the details of certReq,pem. The code is like
>> self signing, but I have added new functions to enter additional issuer
>> details. Now I have two private keys one from CA, another from CSR, one CSR
>> (certReq.pem) and Signed Certificate (SignedCertificate.pem). In
>> SignedCertificate.pem, the subject details and the issuer details are
>> different. There is no problem with codes.
>>
>> The issue is:
>> I am unable to find out the exact command lines or c/c++ program
>> functions to prove the SignedCertificate.pem is signed or not. I have spent
>> more than one day on researching, but I am end up with confusion. I do not
>> have any digital certificate chain.
>>
>>
>> Could anyone kindly provide any information regarding this.
>>
>> Thanks in advance,
>>
>> --
>> openssl-users mailing list
>> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
>>
>>
>
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] How to prove a Certificate is Signed or not

[J Decker]

https://github.com/d3x0r/sack.vfs/blob/master/src/tls_interface.cc#L1538
this routine does cert validation but I don't thkn that's what you want

this verified on a connection
https://github.com/d3x0r/SACK/blob/master/src/netlib/ssl_layer.c#L274

which boils down to
SSL_get_peer_certificate ,  SSL_get_verify_result

On Thu, May 3, 2018 at 12:06 AM, Anil kumar Reddy <
morthalaanilre...@gmail.com> wrote:

> Hi everyone,
>
> I am new to opennssl and now I am completely confused. Please help me out
> to solve my issue.
>
> I have implemented a code to sign the given CSR certificate (certReq.pem),
> then generate openssl signed Certificate (SignedCertificate.pem) using the
> details of certReq,pem. The code is like self signing, but I have added new
> functions to enter additional issuer details. Now I have two private keys
> one from CA, another from CSR, one CSR (certReq.pem) and Signed Certificate
> (SignedCertificate.pem). In SignedCertificate.pem, the subject details and
> the issuer details are different. There is no problem with codes.
>
> The issue is:
> I am unable to find out the exact command lines or c/c++ program functions
> to prove the SignedCertificate.pem is signed or not. I have spent more than
> one day on researching, but I am end up with confusion. I do not have any
> digital certificate chain.
>
>
> Could anyone kindly provide any information regarding this.
>
> Thanks in advance,
>
> --
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
>
>
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] Has client validated successfully?

[J Decker]

On Tue, Feb 13, 2018 at 9:33 AM, Emmanuel Deloget <log...@free.fr> wrote:

> Hello,
>
> On Tue, Feb 13, 2018 at 7:14 AM, Kyle Hamilton <aerow...@gmail.com> wrote:
>
> > The only thing that the server can know is whether the client has
> > terminated the connection with a fatal alert.  If the client validates
> > presented cert chains, then its continuation with the connection means
> > that it passed validation.  If the client does not, or ignores any
> > given error, then it doesn't mean that it passed validation.
> >
> > In other words, you can only know if the client's applied policy
> > allows the connection to continue.  You cannot know if the policy that
> > was applied was specifically related to the certificate chain
> > presented.
> >
> > -Kyle H
> >
> > On Mon, Feb 12, 2018 at 10:06 PM, J Decker <d3c...@gmail.com> wrote:
> > > Is there a way for a server to know if the client verified the cert
> chain
> > > successfully or not?
> >
>
> ​From a security PoV, that doesn't help much. One can build a malicious
> version of openvpn that will tell you "everything's ok" (or "it failed!",
> depending of its goal)​. The server should not make any decision w.r.t. the
> client state (that's more or less what is implied by Kyle's answer ; I just
> wanted to stress it).
>
>
Yes that is true however here's the scenario.
Client does a verification and passes or fails, and via the SSL layer I can
query if the client validated the certificate.
If it failed, provide a option for the client to get a renewed certificate
for verification.  If success, no action.
If an actor lies in this scenario he answers
lies *yes* and didn't, don't give him a means to actually verify. *noop*
lies *no* but did, then give him the root cert he already has *noop*

so I don't have to trust the reply I'm willing to give him the right
root.


> BR,
>
> -- Emmanuel Deloget
>
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

[openssl-users] Has client validated successfully?

[J Decker]

Is there a way for a server to know if the client verified the cert chain
successfully or not?
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] Correct way to free SSL_CTX* ?

[J Decker]

On Sun, Jan 28, 2018 at 7:05 PM, pratyush parimal <
pratyush.pari...@gmail.com> wrote:

> Hi all,
>
> I'm trying to write an application in which I create an instance of
> SSL_CTX* using SSL_CTX_new(), and set the following things in it:
>
> (1) An EVP_PKEY* :
> 1a> created with PEM_read_bio_PrivateKey().
> 1b> set in the ctx using SSL_CTX_use_PrivateKey().
>
after setting key, free key

>
> (2) A number of X509* instances (cuz chained certs) :
> 2a> all created with PEM_read_bio_X509().
> 2b> set in the ctx using SSL_CTX_use_certificate() or
> SSL_CTX_add_extra_chain_cert().
>
after setting certs, free certs.

>
> At the end, I use SSL_CTX_free() to free up the ctx. According to the man
> page for SSL_CTX_free():
>
> "SSL_CTX_free() decrements the reference count of ctx, and removes the
> SSL_CTX object pointed to by ctx and frees up the allocated memory if the
> the reference count has reached 0.
>It also calls the free()ing procedures for indirectly affected
> items, if applicable: the session cache, the list of ciphers, the list of
> Client CAs, the certificates and keys. "
>
> ... which tells me that freeing the SSL_CTX should free up its memory as
> well as the things I set inside of it (unless I'm interpreting it super
> wrong?) like " ... certificates and keys".
> The problem is, when run my application under valgrind, I keep seeing
> memory leaks for both steps (1a) and (2a).
>
> I tried to get rid of them, by using EVP_PKEY_free() after I'm done
> setting in step (1b). This works, and the leak for step (1a) goes away.
> When I try to do the same for step (2), i.e. calling X509_free() after
> every successful "set" call, I get a coredump (backtrace is attached:
> bt_1.txt), coming out of SSL_CTX_free, suggesting that I did something
> wrong.
>
>
> Which brings me to my question, does anyone know the correct way to free
> memory in SSL_CTX ? Or, what's wrong with my steps? The application doesn't
> even perform SSL yet, I'm just trying to create/destroy SSL_CTX objects
> without leaks first. Any help would be appreciated!
>
>
> Thanks in advance,
> -Pratyush.
>
> --
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
>
>
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] Fwd: Information to detach a BIO from fd

[J Decker]

I'm not 100% sure what you're doing
I'd imagine that if SSL was managing the fd's you wouldn't have this issue.
You hvae to call accept() to get a new FD... and you'll only get that once,
so when you accept() you should attach the bio and call ssl_accept(), no?

On Fri, Jan 12, 2018 at 5:52 PM, Priscilla Hero 
wrote:

>
>
> Hi Michael,
> Without doing ssl_accept on the ssl will getpeername work? Also using the
> existing ssl with ssl_accept for the first connection we don’t get the
> information of second peer. Thus we ended up creating new bio/ssl each time
> we get a request.
>
> Any suggestions?
>
> Thanks,
> Grace
>
> On 12-Jan-2018, at 6:45 PM, Michael Wojcik 
> wrote:
>
> >> From: openssl-users [mailto:openssl-users-boun...@openssl.org] On
> Behalf Of Grace Priscilla Jero
> >> Sent: Friday, January 12, 2018 07:04
> >
> >
> >> Whenever a connect is initiated from any client we need to know if it
> is already connected client or a new client.
> >> We are doing this by
> >> • creating bio/ssl each time a polling happens on the server fd
> >> • fetching the peer using BIO_dgram_get_peer after ssl_accept
> >> • Comparing it to the internally maintained list of peer
> >
> > Don't create the BIO immediately. Use getpeername on the socket
> descriptor and check that against the list. Only create a new SSL object
> and BIO if it's not an already-established client.
> >
> > --
> > Michael Wojcik
> > Distinguished Engineer, Micro Focus
> >
> >
> > --
> > openssl-users mailing list
> > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
> --
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
>
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] cert chain file ordering question

[J Decker]

The certs are built into a stack... they are pushed... so element 0 is the
last thing in the list.
The chain starts with 0, and then can search the rest.


On Tue, Jan 9, 2018 at 2:55 PM, Norm Green 
wrote:

> On 1/9/2018 6:03 AM, Benjamin Kaduk wrote:
>
>> Did you try something like (with a 1.1.0 installation):
>>
>> openssl verify -CAfile RootCA.pem -untrusted chain.pem chain.pem
>>
>> with the leaf certificate as the first one in chain.pem?
>>
>
> Same result. The only way it seems to work is if the leaf cert appears at
> the end of the file.
>
> Norm
>
>
> --
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
>
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] Sudden control data sent during large transfer.

[J Decker]

I found the real issue... recently I fixed a signed/unsigned comparison
warning by adding a (int) to the unsigned side, which made the result of
send() be compared differently, and was triggering when send() would return
-1 (with EAGAIN/WSAEWOULDBLOCK) would cause me to think it was a short send
( result < amount_to_send ) { /* sent less than full packet */ }  so I
ended up backing up the send offset by 1 byte instead of 0 bytes... this
was then injecting 1 extra byte into the TCP layer.


On Mon, Dec 25, 2017 at 1:38 PM, Jakob Bohm <jb-open...@wisemo.com> wrote:

> On 23/12/2017 04:06, J Decker wrote:
>
>> How can I know what/why openssl is sending control data?
>>
>> It's variable by the time it starts sending 31 byte packets... Also
>> depends on the connection; although at this time I'm able to generate the
>> problem on localhost... I was able to transfer from a remote server to
>> myself with no issues...
>>
>> I think you need to be a lot more clear for anyone to understand your
> problem.
>
> What exactly do you mean by "control data"?
>

alerts/HelloRequest/renegotation?


>
> What is the layering of protocols here?
> Is it:
>bulk data => WebSockets => TLS => TCP => network
>
> In what direction is the bulk data being sent: TLS client to TLS
> server or TLS server to TLS client?
>
server to client.

>
> In what direction is the initial 31 byte "control packet" being
> sent: TLS client to TLS server or TLS server to TLS client?
>
> client to server

> Also, if possible, could you report the (decrypted if applicable)
> content of those initial 31 bytes?  Perhaps also the later 31 byte
> packets (including their order of occurrence and direction of
> transmission)?
>
> Can you see what the "packets" are?
>

I wouldn't know the decrypted bytes because I would get them from the wbio
from the TLS Object.
Well that's kinda what I was more asking; can I somehow register a callback
for when alerts are generated so I can see what they are?  Otherwise I
really don't know.



>
> For example, are they TLS alert messages?
>
> Are they TLS HelloRequest messages?


>
> Enjoy
>
> Jakob
> --
> Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
> Transformervej 29, 2860 Søborg, Denmark.  Direct +45 31 13 16 10
> This public discussion message is non-binding and may contain errors.
> WiseMo - Remote Service Management for PCs, Phones and Embedded
>
> --
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
>
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] Evaluation of OpenSSL stack software

[J Decker]

On Fri, Dec 22, 2017 at 8:40 PM, Viktor Dukhovni <openssl-us...@dukhovni.org
> wrote:

>
>
> > On Dec 22, 2017, at 11:33 PM, J Decker <d3c...@gmail.com> wrote:
> >
> > Very similar to OpenSSL 1.0.2, plus its own extensions.  That's not
> exactly
> > "same".
> >
> > The same in that I can link/compile against either and not change any
> application code... not speaking of internals, just the API.
>
> Well, that's not actually true.  There are API differences.  There
> is a large common intersection that covers many legacy applications,
> but newer features in each library are not present in the other.
>

Any many current applications.  This app was all done with recent docs on
recent version and I found 0 incompabilities.
I did run into a beta feature for 1.1.0 that was something about setting
the fragment size...
https://github.com/libressl-portable/portable/issues/214  but again that
wasn't in 1.0 stable openssl either so...


>
> --
> --
> Viktor.
>
> --
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
>
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] Evaluation of OpenSSL stack software

[J Decker]

On Fri, Dec 22, 2017 at 7:23 PM, Viktor Dukhovni <openssl-us...@dukhovni.org
> wrote:

>
>
> > On Dec 22, 2017, at 10:21 PM, J Decker <d3c...@gmail.com> wrote:
> >
> > I would also suggest check out LibreSSL which uses the same API as
> OpenSSL
>
> Very similar to OpenSSL 1.0.2, plus its own extensions.  That's not exactly
> "same".
>

The same in that I can link/compile against either and not change any
application code... not speaking of internals, just the API.

>
> --
> Viktor.
>
> --
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
>
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] Evaluation of OpenSSL stack software

[J Decker]

On Fri, Dec 22, 2017 at 4:44 AM, Jan Graczyk  wrote:

> Hello OpenSSL-Users,
>
>
>
> I am actually evaluating OpenSSL stack software to be possibly used in my
> company next generation products. We would like to have a secure connection
> between our device TCP/IP stack and web server which already has SSL server
> running. I am looking for a benchmarks of OpenSSL client running on ARM
> Cortex-M3 based processor. I would appreciate very much  feedback from you.
> Thank you.
>
>
>

I would also suggest check out LibreSSL which uses the same API as OpenSSL
but was easier to build (not requiring perl) and supports CMake.


> Best Regards
>
> *Jan Graczyk*
>
> Embedded Software Developer – Embedded Software Poland
> --
>
> Tel:   +48 535 045 515 <+48%20535%20045%20515>
>
> Tel2: +49-89-673460-635 <+49%2089%20673460635>
>
> E-Mail: j.grac...@telic.de
>
> Web:www.telic.de
>
> *Telic AG*
>
> Raiffeisenallee 12b
>
> 82041 Oberhaching
>
> Germany
>
> [image: cid:image003.png@01D2336E.70B45010]
> --
>
> Local Court Munich, Register Number: HRB 143 723 | Vorstandsvorsitzender:
> Dr. Ditmar Prigge; Vorstand: Frank Heineck
>
>
>
> --
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
>
>
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

[openssl-users] Sudden control data sent during large transfer.

[J Decker]

How can I know what/why openssl is sending control data?
I have this Node addon that uses TLS 1.2 to communicate.  I'm sending a
large file transfer (100M), which is chunked into 8100 byte blocks and sent
on websocket protocol.  It's additionally chunked into 4327 byte blocks
(which after encoding is 4356 bytes or 1452*3)  All of the data is encoded
into blocks and queued to transfer before I have a problem.
After some amount of data transfer OpenSSL starts sending 31 byte control
packets after basically each block received... when the other side receives
that data it doesn't do anything, but the ssl layer does stop giving me
completed packets (instead opting to generate 31 byte packets) when the
other side receives those, it doesn't do anything (doesn't generate
control sends back).

Ad I mentioned all of the pendijng data is already queued to send, so even
if I received a control packet and it generated a response it wouldn't get
received for quite some time.

I don't have control over what version of SSL is being used... but this
current test is 1.0.1m

It's variable by the time it starts sending 31 byte packets... Also depends
on the connection; although at this time I'm able to generate the problem
on localhost... I was able to transfer from a remote server to myself with
no issues...
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] Certificate Verify and non-root Trust Anchors

[J Decker]

I'm pretty sure you need the root also, not just the intermedia ca...
I use a custom generated chain... I encode the root cert in the
application, and then pass it when inintializing the client socket.

This bit of code takes the root cert and adds it to the SSL_CTX the client
socket is created from
https://github.com/d3x0r/SACK/blob/master/src/netlib/ssl_layer.c#L704
( if no root passed, it loads root certs from windows store; haven't
finished linux load cert store)

THis is where the cert chain is verified
https://github.com/d3x0r/SACK/blob/master/src/netlib/ssl_layer.c#L264

looking at that, I guess I should split that if and fail if it fails to get
the peer certificate...

On Mon, Dec 11, 2017 at 3:03 PM, Dr. Pala  wrote:

> Hi Victor,
>
> thanks :D I just tried to set it and I get a different error now : 22
> (certificate chain too long)... I suspect it is a side effect of using the
> X509_V_FLAG_PARTIAL_CHAIN flag... ? (no chain restrictions are set in the
> certificates themselves...), but I have not dug into the vfy code yet...
>
> ... any suggestion on how to fix this ? Do you think it is actually a bug
> ? ... or am I missing some other configs / setting I should have done for
> the verify param ?
>
> Cheers,
> Max
>
>
> On 12/11/17 3:18 PM, Viktor Dukhovni wrote:
>
>>
>> On Dec 11, 2017, at 5:06 PM, Dr. Pala  wrote:
>>>
>>> Hi all,
>>>
>>> I am trying to verify a certificate and provide the possibility to
>>> directly trust an intermediate CA's certificate (not self-signed). After
>>> setting up the STORE and STORE_CTX and add the intermediate CA to the
>>> trusted certificates, when I use the "X509_verify_cert(ctx)" I get the
>>> usual "unable to get issuer certificate" - which would be fine for a
>>> "non-trusted" cert, but I would expect that to not be an issue for a
>>> trusted certificate.
>>>
>>> Therefore, my question is what is the best method to have that behavior ?
>>>
>>> I tried to use the certificate callback to do that, but there is no
>>> function to get the trusted certificates' stack (i.e., there is a
>>> X509_STORE_CTX_get0_untrusted() but there is no equivalent for the
>>> trusted certificates' stack) - so I could not verify if the current
>>> certificate (in the verify callback call) is in the trusted stack or not...
>>>
>>> Maybe there are flags / trust settings that can be used instead ?
>>>
>> It seems we've neglected to document the X509_V_FLAG_PARTIAL_CHAIN
>> flag, which can be passed to X509_VERIFY_PARAM_set_flags() to
>> permit intermediate trust-anchors.
>>
>> https://www.openssl.org/docs/man1.0.2/crypto/X509_VERIFY_PAR
>> AM_set_flags.html
>> https://www.openssl.org/docs/man1.1.0/crypto/X509_VERIFY_PAR
>> AM_set_flags.html
>>
>>
>>
> --
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
>
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

[openssl-users] How to know maximum sendable fragment size?

[J Decker]

I've been developing this NodeJS plugin, it implements HTTPS server
and now client.
I was having an issue with HTTPS request getting ECONNRESET for no apparent
reason; so I implemented my own request, and ran into the same sort of
issue.  What I was requesting was some .js files from the server, and
apparently
my most recent changes to those files made them larger than some magic
number greater than 4096 but less than 6561.  The server was sending using
OpenSSL (statically linked in the NodeJS executable) on CentOS, and it was
sending the full length of the file as one buffer.  I'm using memory BIO to
interact with the SSL object; The buffer was transmitted as one block. With
my own client, (where I could add debugging) was receiving the full count
of bytes from the server but in two blocks, the first 4096 and the second
2472(something like that).  Because my network read buffer was only 4096
So the first read was short, and caused SSL_read to fail, which I had
initially treated as a failure and terminated my connection.  I then
found I could (almost) check using SSL_pending before getting an error (really
I ended up doing SSL_read( ssl, NULL, 0 ) and then SSL_pending(ssl)
).  But after receiving the full count of bytes and having nothing
else to receive,
the message never completed (read return -1, and error 2, pending
returned 0 ). I manually broke up the transmission to 4356 (3*1452 -29)
bytes so it ends up sending in 3 full tcp buffer units, and that works.
(it's http protocol so it's got higher level gathering for the fragments).
It also works if I revert to using the NodeJS HTTPS request object instead
of my own.

So - how do I know what the maximum amount of data I can send is?

Node TLS object (on which HTTPS is based) has
tlsSocket.setMaxSendFragment(size)(which
defaults to 16384)  but that's about sending, not receiving, so I really
have no idea how big the receive buffer is actually (same as SSL send
fragment default)

I did find https://www.openssl.org/docs/man1.1.0/ssl/SSL_CTX_set_
split_send_fragment.html but there's no get_for fragment size I could
find.  (this would be on the server side that I need to know how much I can
send).

how do I set how big of a fragment I can receive?  Like what if I tried to send
100's of Meg as a single fragment?   (I guess it should auto fragment to
like 16k)

I guess there (will be) SSL_CTX_set_default_read_buffer_len() (1.1.0)

(node's open ssl version)
#  define OPENSSL_VERSION_TEXT"OpenSSL 1.0.2l  25 May 2017"

I guess read should default to something like SSL3_RT_MAX_PLAIN_LENGTH
+ SSL3_RT_MAX_ENCRYPTED_OVERHEAD
(16704)  ?  I wonder why it doesn't.
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users