Re: [openssl-users] stronger Kex

[mlrx via openssl-users]

Hello,
Thank you for this very useful explanation and your time.
I apologize for the delay in response.
Best regards,
benoist.

Le 27/12/2016 à 10:16, Jakob Bohm wrote :
> On 27/12/2016 09:15, mlrx wrote:
>> Le 21/12/2016 à 16:07, mlrx a écrit :
>>> Hello,
>>>
>>> I have two servers for testing purpose :
>>> - debian 6, apache 2.2,   openssl 1.0.1t  (mutu)
>>> - centos 7, apache 2.4.6, openssl 1.0.1e-fips (dedicated)
>>>
>>> Now, these 2 serveurs offers only those ciphers :
>>> TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (0xc030)
>>> TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 (0xc028)
>>> TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (0xc014)
>>>
>>> I have two goals. First, I would like to use at least secp384r1
>>> and second (no problem), use an ECC certificate.
>>>
>>> Is it possible to do it with CHACHA20-POLY1305 ?
>>> Is it possible to use this cipher on those servers ?
>>>
>>> openssl ciphers -V CHACHA20 return an error on each server.
>>> I understand it's because there is no chacha20 cipher (?).
>>>
>>> Why can I connect a server by SSH with chacha20-poly1...@openssh.com
>>> and not using it with Apache ?
>>>
>>> All advices are welcome :-).
>>>
>>> Best regards,
>> Hello,
>> Is somebody could explain me the difference between a message who
>> received an answer and this one ?
>> What's wrong ? RTFM ?
> Even though at least one SSH program (OpenSSH) uses the crypto functions
> from the OpenSSL libcrypto, the SSH protocol is completely unrealted to
> the SSL/TLS security protocol.
> 
> So the ability to use specific settings with SSH is almost completely
> unrelated to the ability to use similarly named settings for SSL.
> 
> One major difference is that SSH identifies cryptographic suites by
> strings that can easily be extended by organizations such as openssh.com.
> 
> In contrast, SSL/TLS identifies cryptographic suites by 16 bit numbers
> specified in RFCs and listed in a table published by IANA/ICANN. Thus
> for SSL/TLS libraries such as OpenSSL can really only provide choices
> that were given an official number in an RFC and added to that table
> as part of the RFC publishing process.
> 
> On top of that, the OpenSSL team has a policy of only implementing new
> SSL/TLS cryptographic suites when the number part of the OpenSSL version
> number changes.  Thus anything not included in the original OpenSSL
> 1.0.2 release will only be available in 1.1.0 or an even later release
> (because they will not be making a 1.0.3 release).  Similarly anything
> not in the original 1.1.0 release will only be in 1.2.0 or later
> (assuming there is no 1.1.1 release).
> 
> Enjoy
> 
> Jakob


-- 
benoist

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

Re: [openssl-users] stronger Kex

[mlrx via openssl-users]

Hello,
I also thank you. It was useful to.
Best regards.
benoist

Le 27/12/2016 à 17:38, Jeffrey Walton wrote :
>> I have two servers for testing purpose :
>> - debian 6, apache 2.2,   openssl 1.0.1t  (mutu)
>> - centos 7, apache 2.4.6, openssl 1.0.1e-fips (dedicated)
>>
>> Now, these 2 serveurs offers only those ciphers :
>> TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (0xc030)
>> TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 (0xc028)
>> TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (0xc014)
>>
>> I have two goals. First, I would like to use at least secp384r1
>> and second (no problem), use an ECC certificate.
>>
>> Is it possible to do it with CHACHA20-POLY1305 ?
>> Is it possible to use this cipher on those servers ?
> 
> You need OpenSSL 1.1.0 or above for ChaCha20/Poly1305:
> 
> $ openssl version
> OpenSSL 1.1.0b  26 Sep 2016
> 
> $ openssl ciphers | tr ':' '\n' | grep -i chacha
> ECDHE-ECDSA-CHACHA20-POLY1305
> ECDHE-RSA-CHACHA20-POLY1305
> DHE-RSA-CHACHA20-POLY1305
> RSA-PSK-CHACHA20-POLY1305
> DHE-PSK-CHACHA20-POLY1305
> ECDHE-PSK-CHACHA20-POLY1305
> PSK-CHACHA20-POLY1305
> 
> Jeff
> 


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

Re: [openssl-users] stronger Kex

[mlrx]

Le 21/12/2016 à 16:07, mlrx a écrit :
> Hello,
> 
> I have two servers for testing purpose :
> - debian 6, apache 2.2,   openssl 1.0.1t  (mutu)
> - centos 7, apache 2.4.6, openssl 1.0.1e-fips (dedicated)
> 
> Now, these 2 serveurs offers only those ciphers :
> TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (0xc030)
> TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 (0xc028)
> TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (0xc014)
> 
> I have two goals. First, I would like to use at least secp384r1
> and second (no problem), use an ECC certificate.
> 
> Is it possible to do it with CHACHA20-POLY1305 ?
> Is it possible to use this cipher on those servers ?
> 
> openssl ciphers -V CHACHA20 return an error on each server.
> I understand it's because there is no chacha20 cipher (?).
> 
> Why can I connect a server by SSH with chacha20-poly1...@openssh.com
> and not using it with Apache ?
> 
> All advices are welcome :-).
> 
> Best regards,

Hello,
Is somebody could explain me the difference between a message who
received an answer and this one ?
What's wrong ? RTFM ?

Best regards,
-- 
benoist
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

[openssl-users] stronger Kex

[mlrx]

Hello,

I have two servers for testing purpose :
- debian 6, apache 2.2,   openssl 1.0.1t  (mutu)
- centos 7, apache 2.4.6, openssl 1.0.1e-fips (dedicated)

Now, these 2 serveurs offers only those ciphers :
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (0xc030)
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 (0xc028)
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (0xc014)

I have two goals. First, I would like to use at least secp384r1
and second (no problem), use an ECC certificate.

Is it possible to do it with CHACHA20-POLY1305 ?
Is it possible to use this cipher on those servers ?

openssl ciphers -V CHACHA20 return an error on each server.
I understand it's because there is no chacha20 cipher (?).

Why can I connect a server by SSH with chacha20-poly1...@openssh.com
and not using it with Apache ?

All advices are welcome :-).

Best regards,
-- 
benoist
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] good riddance to PayPal

[mlrx]

Le 06/05/2016 17:06, Steve Marquess a écrit :
> [...]
> 
> That is definitely true, which is how I was able to get our local U.S.
> bank here to allow signature access to our accounts by non-U.S.
> colleagues. It's important that our OpenSSL funding not be accessible by
> only one person, as that person could be run over by a beer truck.
> 
> Unfortunately a U.S. bank is less than ideal for a non-U.S. centric
> organization with funding largely originating from, and spent, outside
> the U.S.
> 
> We have been less successful in finding a non-U.S. bank willing to have
> us as a customer, and not for lack of trying. If you know of a
> *specific* bank that would help us please name it (offline if need be).
> If we haven't already tried them we will.
> 
>> Throw in the prospect of earning transaction fees on an
>> associated Merchant account, and motivation can grow
>> further.
> 
> The U.S. payment processors I've talked to don't like the fact that our
> web servers are all located outside the U.S. Based on an offline tip
> from another user I've spent a good part of this morning on the phone
> with a global payments provider; we're at the familiar "uh, we'll have
> to run this by underwriting" stage.
> 
> -Steve M.

Hello,

Maybe the french ethical and cooperative bank "LA NEF" ?

Their views must be reconciled with the "free world." Their status
has recently changed to become a full-power rights bank; their range
of service is not yet complete but they are working hard to make them
born.

best regards,
-- 
benoist

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

Re: [openssl-users] ciphers

[mlrx]

Le 17/02/2016 07:09, Viktor Dukhovni a écrit :
> On Wed, Feb 17, 2016 at 06:29:43AM +0100, mlrx wrote:
> 
>> I have asked stupid questions or it isn't the right way to ask for
>> advices ? What's happening ?
> 
> I, for one, typically ignore posts that ask me to view detached
> content via pastebin and the like.  Present content relevant to
> your question in the body of the message, and try to ask one specific
> and clear question at a time.
> 
> It sounds like you want TLS best-practice advice.  See,
> 
> https://tools.ietf.org/html/rfc7525

Hello Viktor, thanks for answering.

It all about habits : others ml don't want to overload a thread
with logs anq others big stuff.

The question is : "do I need to do better to secure it?"

Thanks a lot and for the link : it's really useful.

I add my first message with all parts here :
> 
> I have some questions that I don't find answers by myself,
> even after read the cookbook and a lot of web pages.
> To be honest, I'm not really sure it's a problem but I
> need to verify.
> 
> Ok. I am setting up web server to host a critical java application.
> There is Apache in front of Tomcat and I want to enforce connections
> over https only with higher ciphers from TLS 1.2.
> Is it a good way ?

> There is a part of Apache's settings :
> ssl.conf :
>> # Apache 2.4
>> SSLCipherSuite   HIGH:kEECDH:+ECDSA:ECDSA:kEECDH:kEDH:+SHA:STRENGTH: 
>>   \
>>  
>> !aNULL:!eNULL:!LOW:!MEDIUM:!3DES:!MD5:!EXP:!RC4:!DSS: \
>>  !PSK:!SRP:!kECDH:!CAMELLIA:!IDEA:!SEED
>> SSLHonorCipherOrder  on
>> SSLProtocol  -All +TLSv1.2
>> SSLCompression   off
>> SSLInsecureRenegotiation off

> the vhost file :
>> 
>> ServerName   xxx
>> ServerAdmin  xxx
>> DocumentRoot xxx
>> ErrorLog xxx
>> CustomLogxxx
>> LogLevel warn
>> 
>> 
>> Options FollowSymLinks
>> AllowOverride All
>> 
>> 
>> 
>> Options Indexes FollowSymLinks MultiViews
>> AllowOverride All
>> Order allow,deny
>> allow from all
>> 
>> 
>> ScriptAlias /cgi-bin/ /usr/lib/cgi-bin/
>> 
>> 
>> AllowOverride None
>> Options +ExecCGI -MultiViews +SymLinksIfOwnerMatch
>> Order allow,deny
>> Allow from all
>> 
>> 
>> 
>> AllowOverride None
>> Options Indexes MultiViews FollowSymLinks
>> Order deny,allow
>> Deny from all
>> Allow from 127.0.0.0/255.0.0.0 ::1/128
>> 
>> 
>> 
>> JkMount /* ajp13_worker
>> JkMount / ajp13_worker
>> 
>> 
>> 
>> SSLEngine on
>> ServerSignature Off
>> BrowserMatch .*MSIE.* nokeepalive ssl-unclean-shutdown downgrade-1.0 
>> force-response-1.0
>> SSLOptions +FakeBasicAuth +ExportCertData +StrictRequire
>> SSLCertificateFile xxx
>> SSLCertificateKeyFile  xxx
>> 
>> 

> 
> The public part works good, no problem.
> For the moment (testing), I use an auto-signed certificate.
> Of course, I will use "real" CA signed EV certificate in
> production.
> 
> Well, I've did some tests. Here is a part of some nmap and testssl.sh
> results :
>
>> ###
>> nmap --script ssl-cert,ssl-enum-ciphers -p 443 my.dn.tld
>> 
>> # 443/tcp open  https
>> # | ssl-cert: Subject: x
>> # |   Issuer:  x
>> # | Public Key type: ec
>> # | Public Key bits: 256
>> # | Not valid before: 2016-01-05T08:13:37+00:00
>> # | Not valid after:  2017-01-04T08:13:37+00:00
>> # | MD5:   1fc9 5b87 be04 a6a8 0939 d05d 3f24 675a
>> # |_SHA-1: 21be 7dd4 2500 c813 89cc a9c0 ca9a 329a 8beb 9159
>> # | ssl-enum-ciphers: 
>> # |   SSLv3: No supported ciphers found
>> # |   TLSv1.2: 
>> # | ciphers: 
>> # |   TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA- strong
>> # |   TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256 - strong
>> # |   TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 - strong
>> # |   TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA- strong
&

Re: [openssl-users] ciphers

[mlrx]

Le 12/02/2016 19:15, mlrx a écrit :
> Hello !
> 
> I have some questions that I don't find answers by myself,
> even after read the cookbook and a lot of web pages.
> To be honest, I'm not really sure it's a problem but I
> need to verify.
> 
> Ok. I am setting up web server to host a critical java application.
> There is Apache in front of Tomcat and I want to enforce connections
> over https only with higher ciphers from TLS 1.2.
> [...]
> 
> Best regards,

Hello !

I have asked stupid questions or it isn't the right way to ask for
advices ? What's happening ?

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

[openssl-users] ciphers

[mlrx]

Hello !

I have some questions that I don't find answers by myself,
even after read the cookbook and a lot of web pages.
To be honest, I'm not really sure it's a problem but I
need to verify.

Ok. I am setting up web server to host a critical java application.
There is Apache in front of Tomcat and I want to enforce connections
over https only with higher ciphers from TLS 1.2.
Is it a good way ?

There is a part of Apache's settings :
ssl.conf :

the vhost file :


The public part works good, no problem.
For the moment (testing), I use an auto-signed certificate.
Of course, I will use "real" CA signed EV certificate in
production.

Well, I've did some tests. Here is a part of some nmap and testssl.sh
results :


Is everything ok or do I need to change something ?
Could you give some advice to make it safer please ?
I really want to be closer to the state of the art and understand it.

A last thing : please, accept my apologies... I don't speak english
anymore since many many years.

Best regards,
-- 
benoist

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