Re: [openssl-users] Initialising OpenSSL more than once - how do we handle this?

[Marty G]

On 07/30/2018 03:27 PM, Viktor Dukhovni wrote:


The only time such "leaks" come into play is process exit and library
unload.  My advice is to not unload the library and to accept the
fact that a small fixed amount of memory might not be deallocated
at exit.  Typically, even "valgrind" will not report "leaks" for
addresses that are still referenced, so the static allocations
are not a problem.

Spending valuable cycles to eliminate these is not the most productive
use of our time.

How often does a process exit?  Only once.  After a process running for 
billions of cycles in thousands or millions of loops and whatnot I 
hardly think the relative few at the end for clean up could remotely be 
considered "valuable" relative to the total number of cycles executed in 
life of the process.  Unless you are talking about developer's time and 
not the processes time.  In which case I still disagree, but it is your 
time not mine so I won't go there.  I think the forest is being missed 
for the trees here, but I'm going to bow out as I've said my piece

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

Re: [openssl-users] Initialising OpenSSL more than once - how do we handle this?

[Marty G]

On 07/30/2018 02:34 PM, Salz, Rich via openssl-users wrote:


  * So why not just have a rule "don't litter"

Have you looked at, say, the memleak testing we do?

Thanks for the two cents.


Of course I applaud the team's memleak testing!  How could my post be 
interpreted otherwise?  I wasn't trying to single anyone out, just the 
general idea that any memory leak is of little concern when the 
implications of the leak aren't fully known if the cause of the leak 
isn't known, and if one knows the cause, why not deal with it as simple 
good practice?


But nothing beats good programming habits for cleaning up, i.e. "not 
littering" in the first place, as after the fact testing doesn't 
necessarily catch all cases where leaks can occur.  Analogous care at 
the programming stage applies to buffer overruns also as catching them 
after the fact is a dynamic trap shoot.  Same philosophy though.  As 
previously noted by another in this thread, the memleak may be load or 
data size dependent.  Or it may be dependent on some intermittent state 
of the underlying OS.  Some leaks can occur from structures accessed 
only via handles to the process and the OS doesn't necessarily release 
those structures when a process exits. But if the dev *always* 
explicitly makes the call to the system to release those structures via 
the handle then one can be far less concerned about the implications 
about what the system will or won't do if one doesn't


For what it is worth, from my view, I'm addressing a small percentage of 
developers out there who may have not considered the implications of 
some of this and how easy it can be avoided altogether with some simple 
practices at code time, rather than trying to mop up later in dynamic 
testing.  I have nothing but the highest respect and gratefulness for 
the sweat and care behind openssl and wouldn't be posting at all if I 
didn't, so thank you!



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

Re: [openssl-users] Initialising OpenSSL more than once - how do we handle this?

[Marty G]

On 07/30/2018 01:27 PM, Salz, Rich via openssl-users wrote:

> I never thought I'd see the day that someone would have to defend 
not leaking memory in pivotal security code like openssl however


To be accurate, it was a couple of people saying that memory leaks *on 
process exit* aren’t be a big deal.



Fair enough, but it is my understanding that some RTOSes do not 
necessarily dealloc all memory alloc'd by a proc on proc exit.  So why 
not just have a rule "don't litter" instead of having complicated rules 
of when it is "probably ok to litter"?  Exploits nearly always leverage 
something programmers didn't anticipate or happens in a layer they are 
relying on but not directly coding so it seems fairly clear that the 
best path is to reduce those unknowns by explicitly cleaning up.  Taking 
the time to track down a memory leak rarely results in merely fixing a 
memory leak; usually another programming misstep is also found in 
conjunction with the leak. Just my $0.02
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] Initialising OpenSSL more than once - how do we handle this?

[Marty G]

On 07/30/2018 12:52 PM, Jordan Brown wrote:

Because a zero-leaks policy is a lot easier to manage than having to 
make a judgement call on each leak whether or not it's important, and 
having to filter out "unimportant" leaks when you're trying to find 
out whether you've introduced any "important" leaks.


Maybe the test suite only caused the program to leak one buffer, but 
that doesn't tell you whether a real workload (or a malicious 
workload) will leak gigabytes.

--
Jordan Brown, Oracle Solaris


^^^ this

So much has changed in programming culture over the decades for me to be 
able to call it "engineering" any more.  Too much code equivalents of 
duct tape, chewing gum, and kite string holding things together out 
there and so many consider that normal and ok. I never thought I'd see 
the day that someone would have to defend not leaking memory in pivotal 
security code like openssl however
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] How to form a proper hash after writing somethinginto SSL handshake.

[Marty G]

For the same reason one doesn't wear a halloween costume to a technical 
meeting, Comic Sans is looked down upon when used outside comics and 
day-care centers.  It is considered a snub to use it in non-trivial 
settings.


Much as lifting up your middle finger has no inherent meaning per se, 
but once one realizes that it definitely has meaning to others and one 
lifts one's middle finger to others anyway, it can only be assumed that 
one has intended to send the message others have assigned to it.  So, 
for whatever vague societal reasons, comic sans has become equivalent to 
wearing a speedo to a formal wedding, giggling hysterically during one's 
performance review, or skipping around the track in a tu-tu and 
clownface during the 440 meter track event at the Olympics.  Those are 
the breaks!  Sorry for your loss of a connotation free comic sans.  I 
feel your pain.  Herd dynamics can be brutal and bleak.


http://knowyourmeme.com/memes/comic-sans
"...While adequate for certain industry sectors like childcare and 
entertainment, its usage in business or professional settings has been 
criticized by many aesthetic-conscious Internet users, who say Comic 
Sans conveys silliness and irreverence that is hardly suitable for 
serious matters:


On 12/29/2017 08:14 AM, Sai Teja Chowdary wrote:


Why? What is the problem with Comic Sans. I like it!

You can say more if you have something useful.

Thanks

Saiteja.

*From: *Michael Sierchio 
*Sent: *Friday, December 29, 2017 10:38 AM
*To: *openssl-users@openssl.org 
*Subject: *Re: [openssl-users] How to form a proper hash after writing 
somethinginto SSL handshake.


Comic Sans. Need I say more?

On Tue, Dec 26, 2017 at 4:53 AM, Sai Teja Chowdary 
> wrote:


Hi,

Happy Holidays everyone.

I want to send client certificate, client key exchange and client
verify in a single handshake message which appears as multiple
handshake messages in a single record. But to sent the client
verify I need to first make a hash of previous messages(client
certificate and client key exchange) to create the signature.

Can anyone help me to find the function in OpenSSL 1.1.1-dev  xx
XXX  (or right procedure that needs to be done before creating
a certificate verify message)that can do a proper
transcript(digest or hash not clear). I tried using
*ssl3_finish_mac() *on the message containing client certificate
and client key exchange and then tried to generate the signature
in certificate verify message.

But it is giving me a digest error. I am new to the mailing list
want a bit of help to proceed forward stuck here. Please reply in
case if anything is not clear.

Here is a code snippet, how I am forming the data containing all
client certificate , client key exchange and certificate verify
messages inside write_state_machine().

if(WPACKET_init(, s->init_buf)){

//Client certificate formation

if(!ssl_set_handshake_header(s,,mt) || confunc != NULL &&
!confunc(s,) || !ssl_close_construct_packet(s,,mt)){

printf("PROBLEM\n");

    }

 transition(s); //transition to next state i.e client
key exchange

get_construct_message_f(s, , , );

//client key exchange formation

if(!ssl_set_handshake_header(s,,mt) || confunc != NULL &&
!confunc(s,) || !ssl_close_construct_packet(s,,mt)){

   printf("AGAIN A PROBLEMO\n");

    }

//ssl3_finish_mac(s, >init_buf->data[s->init_off], s->init_num);

st->write_state_work = post_work(s, st->write_state_work);

 transition(s);  // transition to next state i.e
 certificate verify

get_construct_message_f(s, , , );

//certificate verify message formation.

if(!ssl_set_handshake_header(s,,mt) || confunc != NULL &&
!confunc(s,) || !ssl_close_construct_packet(s,,mt)){

   printf("AGAIN A PROBLEMO\n");

    }

WPACKET_finish();

Please take a look at it, appreciate every bit of help.

Regards,

Saiteja


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



--

"Well," Brahma said, "even after ten thousand explanations, a fool is 
no wiser, but an intelligent person requires only two thousand five 
hundred."



- The Mahābhārata





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