openssl on freestos?

[Wall, Stephen]

Is anyone out there building OpenSSL for a FreeRTOS system?  If so, was it a 
difficult port, and what are the main changes that were necessary?

Thank you.

- Steve Wall

RE: enforcing mutual auth from the client

[Wall, Stephen]

> From: openssl-users  On Behalf Of Viktor 
> Dukhovni
> 
> Of course this test should only be applied for a full handshake, reused 
> sessions
> piggyback on the certificates exchanged in the original full handshake.

Thank you, that helps.  I have not enabled session cache, so that's not a 
concern.
- Steve

RE: enforcing mutual auth from the client

[Wall, Stephen]

> A compromised server could easily still request the client certificate, no?

> But as noted, even a compromised server can ask for client credentials and 
> then

Yes, that's true.  If the intruder knew to do so.  Also, a thief can break your 
window and get into your car, so you might as well leave them rolled down all 
the time.

The question wasn't "Should I care that..."  or "Is it a good idea to...".  It 
was "Can OpenSSL 3 do this".

 

RE: enforcing mutual auth from the client

[Wall, Stephen]

> It is not clear what threat model warrants taking special action when the 
> client
> certificate is not requested.  It could equally be requested and then largely
> ignored.

A client in a highly secured network knows that every server it connects to 
will require a client certificate.  If the request fails to arrive, it's either 
a misconfiguration or a compromised server.  In either case, the client prefers 
to fail and make the user aware of a problem rather than risk compromising 
sensitive data with the user unaware that there was unexpected behavior.

enforcing mutual auth from the client

[Wall, Stephen]

Does OpenSSL 3.0 provide a way for client side software to verify that the 
server actually sent a request for the client’s certificate?  As I recall, the 
only way to do this in 1.0.2 was to hook in a callback that examined every 
handshake message and set a flag if the client cert request was seen, then 
check that flag after handshake completion in the application.  I hope there is 
something better available in 3.0…

Thanks
- Steve

Re: [openssl-users] Disabling Client-Initiated TLS renegotiation

[Wall, Stephen]

I suppose one could abuse SSL_set_msg_callback() to create a filter that 
rewrites the initial re-handshake message into something innocuous.  Though I 
doubt that would work, once the client starts a handshake, it expects a 
response from the server, and may well time out and close if it does not get 
one.  The way TLS works, it is always the client starting a renegotiation.  The 
server can send a message asking the client to renegotiate, but the client can 
ignore that. I don't believe the opposite is true.

From: openssl-users [mailto:openssl-users-boun...@openssl.org] On Behalf Of 
Sashank Mullapudi (samullap)
Sent: Monday, November 28, 2016 10:56 PM
To: openssl-users@openssl.org
Cc: Ram Mohan R (rmohanr) ; Nikhil Mittal (nimittal) 
; Anil Kumar (anilkum) 
Subject: Re: [openssl-users] Disabling Client-Initiated TLS renegotiation

Resending this hoping for a response from someone who has information on 
disabling TLS renegotiation from the Client side.

Thanks,
Sashank

From: samullap >
Date: Tuesday, 22 November 2016 at 12:21 PM
To: "openssl-users@openssl.org" 
>
Cc: "Ram Mohan R (rmohanr)" >, 
"Anil Kumar (anilkum)" >, "Nikhil 
Mittal (nimittal)" >
Subject: Disabling Client-Initiated TLS renegotiation

Hi,

As part of securing our web interfaces, we wanted to disable client-initiated 
TLS renegotiation.

The reasoning for this requirement is as follows- Generally, renegotiation of 
TLS sessions is much more resource-intensive for the server than the client, 
and should therefore not be performed at will to avoid degrading performance. 
Disabling client from renegotiating secures the server from undergoing a DoS 
attack due to continuous renegotiation requests.

I see that there is an option SSL_OP_ALLOW_UNSAFE_LEGACY_RENEGOTIATION, but 
that is to secure the renegotiation, not disable it.

I wanted to check if there is a patch or flag available to disable any 
negotiation initiated from the client side.

Thanks and Regards,
Sashank
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] Any advice/recommendation for watching TLS version negotiation

[Wall, Stephen]

> From: openssl-users [mailto:openssl-users-boun...@openssl.org] On
> Behalf Of Ludwig, Mark
> 
> A customer claims to have configured the web (app) server to only allow
> TLS 1.2
> (by disallowing up through TLS 1.1), and says that the client code
> (which we
> know is based on OpenSSL 1.0.2j) is nevertheless connecting using TLS
> 1.1.  We
> are setting up a similar environment internally to diagnose what's
> happening,
> and I wonder if anyone has any advice on the "best" tool for "watching"
> the TLS
> version negotiation when the connection is being established.

I've typically used Wireshark for this type of thing.  If you are using RSA and 
have a copy of the server key, you can also examine the encrypted channel 
content.

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

Re: [openssl-users] openssl-users Digest, Vol 24, Issue 16

[Wall, Stephen]

Can this person be dropped from the list?

From: openssl-users [mailto:openssl-users-boun...@openssl.org] On Behalf Of 
Hello Notelling
Sent: Tuesday, November 08, 2016 9:47 AM
To: openssl-users@openssl.org
Subject: Re: [openssl-users] openssl-users Digest, Vol 24, Issue 16


Your query is being processed

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

Re: [openssl-users] FIPS canister 2.0.12 and 186-4

[Wall, Stephen]

> Does 2.0.12 support 186-4 ?  Specifically, does it support the RSA
> requirements  ?

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

Re: [openssl-users] ECDSA vs RSA certificates

[Wall, Stephen]

> From: openssl-users [mailto:openssl-users-boun...@openssl.org] On Behalf Of 
> Rajeswari K

> Is there a way we can feed multiple certificates i.e. one with ECDSA and 
> other with RSA
> to TLS server during SSL_CTX initialization? 

Yes, you can set a certificate of each known type (DSA, RSA, EC), see the Notes 
section at 
https://www.openssl.org/docs/man1.0.2/ssl/SSL_CTX_use_certificate.html

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

Re: [openssl-users] Is SHA hashing algorithm reversable?

[Wall, Stephen]

> -Original Message-
> From: openssl-users [mailto:openssl-users-boun...@openssl.org] On
> Behalf Of Sugumar
> Sent: Monday, April 04, 2016 9:26 AM
> To: openssl-users@openssl.org
> Subject: [openssl-users] Is SHA hashing algorithm reversable?
>   
> Hi,
> 
> I going to use SHA256 algorithm for storing my passwords in secure
> manner.
> But after reading some documentations related to SHA i come to know it
> is
> not reversable.
> Yes hashing means its not reversable only.
> But i saw some online websites giving the original data by reversing
> the
> hash data.
> is it possible means what is the security of hashing?
> I am totally confused pls clarify my doubt.

Hashes are not reversible.  When used to store passwords, the passwords is 
hashed with a random 'salt', and both the resultant value and the salt are 
stored.  When testing if an entered password is correct, you hash the entered 
password with the stored salt, and if the result matches the stored value, the 
entered password was correct.  Also, generally, a plain hash is not used, it is 
repeated some large number of times, sometimes with addition data added in, to 
slow down and complicate cracking attempts.  Google (or any other search 
engine) can give you lots of links for properly hashing and storing passwords.

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

Re: [openssl-users] [Question] What are the current secure Configure Parameter?

[Wall, Stephen]

> -Original Message-
> From: openssl-users [mailto:openssl-users-boun...@openssl.org] On Behalf Of 
> Oliver Niebuhr
> 
> The Qt Wiki says, the following Parameters are minimum recommended:
> no-ssl2 no-ssl3 no-idea no-mdc2 no-rc5
> 
> My Questions are:
> 1.) Are there any other Parameters that should be used?

I also add no-comp -DOPENSSL_NO_HEARTBEAT no-md2.

no-md2 might be a default.

Check Configure Options at 
https://wiki.openssl.org/index.php/Compilation_and_Installation for some other 
things you might not need, like no-srp no-psk no-dtls no-npn no-krb5 etc.  If 
this is a dedicated library for your application, I suggest you disable all 
features and ciphers you won't be using, for example, no-bf no-sha1 no-md5 
no-seed etc

If you control both ends, you could even distill it down to a single protocol 
cipher suite, like ECDHE-ECDSA-AES128-GCM-SHA256 with TLS1.2.
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] recommended build options

[Wall, Stephen]

> From: openssl-users [mailto:openssl-users-boun...@openssl.org] On
> Behalf Of Viktor Dukhovni
> 
> By and large what should be off by default eventually or already
> is, but there can be some delay for backwards compatibility.
...
> With these you're covered for no-ssl2 no-comp and no weak ciphers.

We are using 1.0.2f, no-ssl2 and no-comp do not appear to be defaults in that 
version.  Should heartbeats be turned off, or have recent version of OpenSSL 
taken care of any potential weaknesses there?

> It may also be reasonable to disable "idea", "seed" and "rc2".

We provide config settings to disable ssl3, idea, and seed, though I think it'd 
probably be safe to drop idea and seed altogether.  I believe heimdal uses rc2, 
which precludes disabling that one.

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

[openssl-users] recommended build options

[Wall, Stephen]

Is there a set of recommended build options for openssl?  For instance, 
"no-ssl2 no-comp -DOPENSSL_NO_HEARTBEATS no-md4 ..."

Thanks

-- 
Stephen P. Wall
stephen_w...@redcom.com
(585) 924-7550
REDCOM Laboratories, Inc.
One Redcom Center
Victor, NY 14564 USA


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

Re: [openssl-users] Apache (2.x) server and OpenSSL FIPS modules

[Wall, Stephen]

See http://httpd.apache.org/docs/2.4/mod/mod_ssl.html#sslfips for using the 
OpenSSL fipscontainer with apache.

From: openssl-users [mailto:openssl-users-boun...@openssl.org] On Behalf Of 
security veteran
Sent: Monday, January 18, 2016 9:21 PM
To: openssl-users@openssl.org
Subject: [openssl-users] Apache (2.x) server and OpenSSL FIPS modules

Hi,

We will be using OpenSSL FIPS modules on our Linux server and was wondering if 
we need to do any work on the Apache server in order to make it working 
seamlessly with OpenSSL when the FIPS mode is enabled.

My questions are:

1) How to make Apache server enable the FIPS mode on OpenSSL? My understanding 
is, for each application which need use OpenSSL FIPS mode, the application need 
to invoke the FIPS_mode_set () API. In that case how do we make Apache to 
invoke this API? Is that a configuration changes or does it require to rebuild 
Apache server?

2) If Apache is enabled with FIPS module, does it mean all the Apache processes 
(when invoking crypto functions from OpenSSL) will be operating with the 
OpenSSL FIPS mode?

Thanks.


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

Re: [openssl-users] explicitly including other ciphers.

[Wall, Stephen]

> What about openssl?  (little confused here)..  I would expect openssl
> being the one that needs to be rebuild, not apache.

As Viktor previously stated, openssl has the NULL ciphers built in by default.  
Your reply to Rich seemed to confirm that your version of openssl does include 
them:

 but if I do a: openssl ciphers -v "ALL:eNULL" | grep eNULL
 I don't see anything.
>>> Look for NULL, not eNULL.  Or "Enc=None"
>> thanks!  that seemed to work,

You further asked:

>> does that means, since there are NULL ciphers I can just use them in 
>> apache/mod_ssl by just changing a setting like:
>>
>> SSLCipherSuite eNULL
>>
>> in httpd.conf?

To which I responded "No".  If mod_ssl were passing the SSLCipherSuite value 
straight through to openssl, the answer would have been yes.  Unfortunately for 
you, mod_ssl manipulates the value of SSLCipherSuite to prevent NULL and export 
ciphers from being used.  You need to rebuild Apache without that manipulation 
to use any NULL ciphers.


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

Re: [openssl-users] explicitly including other ciphers.

[Wall, Stephen]

> So in general, I would have to build apache before I could use null
> ciphers?

That is correct.

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

Re: [openssl-users] explicitly including other ciphers.

[Wall, Stephen]

> Encryption in https/apache is handled by mod_ssl.  does that means,
> since there are NULL ciphers I can just use them in apache/mod_ssl by
> just changing a setting like:
> 
> SSLCipherSuite eNULL
> 
> in httpd.conf?

No.  mod_ssl modifiers the ciphers you specify by appending 
':!aNULL:!eNULL:!EXP' in recent versions, or by prepending 
'!aNULL:!eNULL:!EXP:' in older versions.  There were some releases where it was 
possible to specify ciphers as

SSLOpenSSLConfCMD CipherString "eNULL"

and the ciphers you listed were not modified, but that has since been changed.  
If you are not lucky enough to be using a version of apache that is in that 
window, you will need to obtain the apache source, modify mod_ssl, and build a 
custom version.  Be aware of potential license issues with doing this if it is 
for a deliverable.

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