Re: [openssl-users] How to increase the priority of some cipher ?

[李明]

sorry， write by mistake


TLSv1.2,AES256-GCM-SHA384  ： the server can handle more than 1500 requests per 
second（cpu ： 99%）。
TLSv1.2 ECDHE-RSA-AES256-GCM-SHA384 :  the server can ONLY handle less then 
1400 requests per second（cpu ：99%）。




At 2017-09-27 08:52:01, "李明"  wrote:

The environment is quite simple，client use apachebench to  test the performance 
of a https server
the apachebench command is like this： ab -c 500 -n 100 https://xx.xx.xx.xx/
TLSv1.2,AES256-GCM-SHA384  ： the server can handle more than 1500 requests per 
second（cpu ： 99%）。
TLSv1.2 ECDHE-RSA-AES256-GCM-SHA384 :  the server can ONLY handle 500 requests 
per second（cpu ：99%）。




At 2017-09-27 00:58:43, "Benjamin Kaduk"  wrote:
I am curious about this statement that "(EC)DHE cost much more resources than 
RSA".  In particular, ECDHE is supposed to be less computation-intensive than 
RSA for a given security level, so it would be interesting to hear what your 
setup is where the reverse is supposed to be observed.

-Ben


On 09/26/2017 03:44 AM, 李明 wrote:

just find it, 
 server respect client's cipher preference  by default,  
 it selects the suite preferred by client among the cipherlist that both the 
client and server support.
 so it's not enough to just increase RSA cipher priority on server side ,  
 SSL_OP_CIPHER_SERVER_PREFERENCE will make the server select the suite that 
itself most prefer among the cipherlist that both the client and server support.


在 2017-09-26 15:15:10，"李明"  写道：

Hello, 
   Currently, openssl prefer (EC)DHE handshakes over plain RSA, but (EC)DHE 
cost much more resouces than RSA.
   In order to get higher performance , I want to  prioritize RSA related 
ciphers, does anyone knows how to do it.
   
   I have tried cipherlist "RSA:ALL:!COMPLEMENTOFDEFAULT:!eNULL" , it looks 
fine in openssl command line
   ./openssl ciphers -v 'RSA:ALL:!COMPLEMENTOFDEFAULT:!eNULL' 
AES256-GCM-SHA384   TLSv1.2 Kx=RSA  Au=RSA  Enc=AESGCM(256) Mac=AEAD
AES128-GCM-SHA256   TLSv1.2 Kx=RSA  Au=RSA  Enc=AESGCM(128) Mac=AEAD
AES256-SHA256   TLSv1.2 Kx=RSA  Au=RSA  Enc=AES(256)  Mac=SHA256
AES128-SHA256   TLSv1.2 Kx=RSA  Au=RSA  Enc=AES(128)  Mac=SHA256
AES256-SHA  SSLv3 Kx=RSA  Au=RSA  Enc=AES(256)  Mac=SHA1
AES128-SHA  SSLv3 Kx=RSA  Au=RSA  Enc=AES(128)  Mac=SHA1
ECDHE-ECDSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH Au=ECDSA Enc=AESGCM(256) 
Mac=AEAD


 but, after SSL_CTX_set_cipher_list(ctx, "RSA:ALL:!COMPLEMENTOFDEFAULT:!eNULL") 
 in my application, it didn't work, the first choice is still 
ECDHE-RSA-AES256-GCM-SHA384



【网易自营】好吃到爆！鲜香弹滑加热即食，经典13香/麻辣小龙虾仅75元3斤>>  



【网易自营|30天无忧退货】仅售同款价1/4！MUJI制造商“2017秋冬舒适家居拖鞋系列”限时仅34.9元>>  







【网易自营|30天无忧退货】仅售同款价1/4！MUJI制造商“2017秋冬舒适家居拖鞋系列”限时仅34.9元>>  -- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

[openssl-users] How to uninstall openssl with ``sudo make uninstall''?

[Hongyi Zhao]

Hi all,

I installed the openssl-1.0.0 with the following steps:

$ ./config shared
$ make -j24
$ sudo make install


But when I try to uninstall it, I meet the following error:

$ sudo make uninstall
make: *** No rule to make target 'uninstall'.  Stop.

ps. All of the above steps are performed under the source code root directory.

Regards
-- 
Hongsheng Zhao 
Institute of Semiconductors, Chinese Academy of Sciences
GnuPG DSA: 0xD108493
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] How to increase the priority of some cipher ?

[李明]

The environment is quite simple，client use apachebench to  test the performance 
of a https server
the apachebench command is like this： ab -c 500 -n 100 https://xx.xx.xx.xx/
TLSv1.2,AES256-GCM-SHA384  ： the server can handle more than 1500 requests per 
second（cpu ： 99%）。
TLSv1.2 ECDHE-RSA-AES256-GCM-SHA384 :  the server can ONLY handle 500 requests 
per second（cpu ：99%）。




At 2017-09-27 00:58:43, "Benjamin Kaduk"  wrote:
I am curious about this statement that "(EC)DHE cost much more resources than 
RSA".  In particular, ECDHE is supposed to be less computation-intensive than 
RSA for a given security level, so it would be interesting to hear what your 
setup is where the reverse is supposed to be observed.

-Ben


On 09/26/2017 03:44 AM, 李明 wrote:

just find it, 
 server respect client's cipher preference  by default,  
 it selects the suite preferred by client among the cipherlist that both the 
client and server support.
 so it's not enough to just increase RSA cipher priority on server side ,  
 SSL_OP_CIPHER_SERVER_PREFERENCE will make the server select the suite that 
itself most prefer among the cipherlist that both the client and server support.


在 2017-09-26 15:15:10，"李明"  写道：

Hello, 
   Currently, openssl prefer (EC)DHE handshakes over plain RSA, but (EC)DHE 
cost much more resouces than RSA.
   In order to get higher performance , I want to  prioritize RSA related 
ciphers, does anyone knows how to do it.
   
   I have tried cipherlist "RSA:ALL:!COMPLEMENTOFDEFAULT:!eNULL" , it looks 
fine in openssl command line
   ./openssl ciphers -v 'RSA:ALL:!COMPLEMENTOFDEFAULT:!eNULL' 
AES256-GCM-SHA384   TLSv1.2 Kx=RSA  Au=RSA  Enc=AESGCM(256) Mac=AEAD
AES128-GCM-SHA256   TLSv1.2 Kx=RSA  Au=RSA  Enc=AESGCM(128) Mac=AEAD
AES256-SHA256   TLSv1.2 Kx=RSA  Au=RSA  Enc=AES(256)  Mac=SHA256
AES128-SHA256   TLSv1.2 Kx=RSA  Au=RSA  Enc=AES(128)  Mac=SHA256
AES256-SHA  SSLv3 Kx=RSA  Au=RSA  Enc=AES(256)  Mac=SHA1
AES128-SHA  SSLv3 Kx=RSA  Au=RSA  Enc=AES(128)  Mac=SHA1
ECDHE-ECDSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH Au=ECDSA Enc=AESGCM(256) 
Mac=AEAD


 but, after SSL_CTX_set_cipher_list(ctx, "RSA:ALL:!COMPLEMENTOFDEFAULT:!eNULL") 
 in my application, it didn't work, the first choice is still 
ECDHE-RSA-AES256-GCM-SHA384



【网易自营】好吃到爆！鲜香弹滑加热即食，经典13香/麻辣小龙虾仅75元3斤>>  



【网易自营|30天无忧退货】仅售同款价1/4！MUJI制造商“2017秋冬舒适家居拖鞋系列”限时仅34.9元>>  



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

Re: [openssl-users] Hardware client certificates moving to Centos 7

[Robert Moskowitz]

On 09/26/2017 08:04 PM, Kyle Hamilton wrote:

openssl x509 -noout -text -in clientcertificate.pem

You may need to extract the client certificate from wireshark, but you
could also get it from openssl s_server.

Specifically, that error message is suggesting that there's a message
digest encoded into the certificate which is unknown to the trust
path.

Chances are, it's probably MD5.  MD5 was broken a long time ago, and
is no longer trustworthy.  (SHA1 is also a possibility, but it was
made unacceptable a lot more recently.)


If it IS a 802.1AR RSA cert (the original drivers for 802.1AR was 
protecting VoIP phones), 802.1AR-2009 says:


6.3.5.1 RSA Signing

If the key is an RSA key, then this operation shall generate a PKCS1 
signature as defined in RFC 3447 with

the signature algorithm of RSASSA-PKCS1-v1_5, for maximum interoperability.

The currentEncoding specifies the current encoding of the data. The 
dataOctets are partially encoded for
RFC 3447 signing prior to calling this DevID module interface. A value 
of PKCS1HASH_SHA256
indicates that the dataOctets are a SHA256 hash of the original data as 
specified by RFC 3447 id-sha256.
The DevID Module will continue encoding the data, starting at RFC 3447 
Section 9.2 step 2, by building
and padding the DigestInfo ASN.1 value and then building the full PKCS1 
signature.


A currentEncoding value of PKCS1DIGESTINFO_OPAQUE indicates that the 
dataOctets are already
encoded into the equivalent of the RFC 3447 Section 9.2 step 2 specified 
DigestInfo. The DevID Module
will continue encoding the data, starting at RFC 3447 Section 9.2 step 
3, by padding the dataOctet as
specified for the DigestInfo ASN.1 value, and then building the full 
PKCS1 signature.


NOTE—Some uses of PKCS1 specify an alternative to the RFC 3447 
DigestInfo structure. For example TLS 1.1 RFC4346 specifies “a 36-byte 
structure of two hashes (one SHA and one MD5).” The use of
PKCS1DIGESTINFO_OPAQUE provides support for this type of construct. It 
also provides a mechanism for
components leveraging the DeviceID Module to obtain PCKS1 signatures 
using legacy hash algorithms such as SHA-1 or MD5.



And:

7.3.1 RSASSA-PKCS1-v1.5

The RSASSA-PKCS1-v1.5 signature method is defined in RFC 3447. The 
algorithm shall be either
sha1WithRSAEncryption or sha256WithRSAEncryption. The algorithm 
identifiers are:


sha1WithRSAEncryption OBJECT IDENTIFIER ::= { iso(1) member-body(2)us(840)
rsadsi(113549) pkcs(1) pkcs-1(1) 5 }

sha256WithRSAEncryption OBJECT IDENTIFIER ::= { iso(1) member-body(2)us(840)
rsadsi(113549) pkcs(1) pkcs-1(1) 11 }

Support for sha1WithRSAEncryption is included for maximum 
interoperability but is not recommended.
When the sha1WithRSAEncryption or sha256WithRSAEncryption algorithm 
identifiers appear in the
algorithm field as an AlgorithmIdentifier, the encoding must omit the 
parameters field. That is, the
AlgorithmIdentifier shall be a SEQUENCE of one component, the object 
identifier

sha1WithRSAEncryption or sha256WithRSAEncryption.




-Kyle H


On Tue, Sep 26, 2017 at 8:56 AM, Stuart Marsden  wrote:

Sorry how can I tell ?

I can run a wireshark if necessary

thanks



On 26 Sep 2017, at 16:36, Wouter Verhelst  wrote:

On 26-09-17 17:26, Stuart Marsden wrote:

[ssl:info] [pid 1611] SSL Library Error: error:0D0C50A1:asn1 encoding 
routines:ASN1_item_verify:unknown message digest algorithm

So which message digest algorithm is the client trying to use?

--
Wouter Verhelst
--
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] Hardware client certificates moving to Centos 7

[Kyle Hamilton]

openssl x509 -noout -text -in clientcertificate.pem

You may need to extract the client certificate from wireshark, but you
could also get it from openssl s_server.

Specifically, that error message is suggesting that there's a message
digest encoded into the certificate which is unknown to the trust
path.

Chances are, it's probably MD5.  MD5 was broken a long time ago, and
is no longer trustworthy.  (SHA1 is also a possibility, but it was
made unacceptable a lot more recently.)

-Kyle H


On Tue, Sep 26, 2017 at 8:56 AM, Stuart Marsden  wrote:
> Sorry how can I tell ?
>
> I can run a wireshark if necessary
>
> thanks
>
>
>> On 26 Sep 2017, at 16:36, Wouter Verhelst  wrote:
>>
>> On 26-09-17 17:26, Stuart Marsden wrote:
>>> [ssl:info] [pid 1611] SSL Library Error: error:0D0C50A1:asn1 encoding 
>>> routines:ASN1_item_verify:unknown message digest algorithm
>>
>> So which message digest algorithm is the client trying to use?
>>
>> --
>> Wouter Verhelst
>> --
>> 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] Hardware client certificates moving to Centos 7

[Robert Moskowitz]

On 09/26/2017 11:26 AM, Stuart Marsden wrote:

Hi

I have Centos/Apache servers for securely provisioning IP phones using hardware 
client certificates embedded in the phones.

for this test I have allowed all protocols and ciphers

on Centos 6 this works fine, the rpms are:

openssl098e-0.9.8e-20.el6.centos.1.x86_64
openssl-1.0.1e-57.el6.x86_64
openssl-devel-1.0.1e-57.el6.x86_64

on centos 7 the rpms are:

openssl098e-0.9.8e-29.el7.centos.3.x86_64
openssl-1.0.2k-8.el7.x86_64
openssl-libs-1.0.2k-8.el7.x86_64
xmlsec1-openssl-1.2.20-7.el7_4.x86_64
openssl-devel-1.0.2k-8.el7.x86_64

on Centos 7 the logging with "Loglevel debug"  in the apache config file is a 
lot less than Centos 6


The SSL fails to establish with the error below:


ssl_engine_kernel.c(1890): [client XX.XX.31.200:47576] AH02043: SSL virtual 
host for servername  found

ssl_engine_kernel.c(1360): [client XX.XX.31.200:47576] AH02275: Certificate 
Verification, depth 1, CRL checking mode: none [subject: 
emailAddress=supp...@yealink.com,CN=Yealink Equipment Issuing 
CA,OU=yealink.com,O=Yealink Network Technology 
Co.\\,Ltd.,L=Xiamen,ST=Fujian,C=CN / issuer: 
emailAddress=supp...@yealink.com,CN=Yealink Equipment Issuing 
CA,OU=yealink.com,O=Yealink Network Technology 
Co.\\,Ltd.,L=Xiamen,ST=Fujian,C=CN / serial: E17F3D266C47321E / notbefore: Nov  
7 12:45:52 2013 GMT / notafter: Nov  7 12:45:52 2033 GMT]


Please provide a complete dump of the hardware certificate.  There may 
be a subjectAltName with fields that require an hex dump.  I want to see 
if these are IEEE 802.1AR certificates...


If they are, they are suppose to be used to provision an owner (lDevID) 
certificate.  But they should be usable; they may be ECDSA certs.


You can see some examples on how to create (and display) ECDSA 802.1AR 
certs in:


https://datatracker.ietf.org/doc/draft-moskowitz-ecdsa-pki/




ssl_engine_kernel.c(1360): [client xx.xx.31.200:47576] AH02275: Certificate 
Verification, depth 0, CRL checking mode: none [subject: 
emailAddress=supp...@yealink.com,CN=001565c8be6f,OU=Yealink Equipment,O=Yealink 
Network Technology Co.\\,Ltd.,L=Xiamen,ST=Fujian,C=CN / issuer: 
emailAddress=supp...@yealink.com,CN=Yealink Equipment Issuing 
CA,OU=yealink.com,O=Yealink Network Technology 
Co.\\,Ltd.,L=Xiamen,ST=Fujian,C=CN / serial: 303031353635633862653666 / 
notbefore: Mar  1 00:00:00 2014 GMT / notafter: Feb 24 00:00:00 2034 GMT]

[ssl:info] [pid 1611] [client xx.xx.31.200:47576] AH02276: Certificate 
Verification: Error (7): certificate signature failure [subject: 
emailAddress=supp...@yealink.com,CN=001565c8be6f,OU=Yealink Equipment,O=Yealink 
Network Technology Co.\\,Ltd.,L=Xiamen,ST=Fujian,C=CN / issuer: 
emailAddress=supp...@yealink.com,CN=Yealink Equipment Issuing 
CA,OU=yealink.com,O=Yealink Network Technology 
Co.\\,Ltd.,L=Xiamen,ST=Fujian,C=CN / serial: 303031353635633862653666 / 
notbefore: Mar  1 00:00:00 2014 GMT / notafter: Feb 24 00:00:00 2034 GMT]

[ssl:info] [pid 1611] [client xx.xx.31.200:47576] AH02008: SSL library error 1 
in handshake (server xxx.xxx.xxx.xxx:443)
[ssl:info] [pid 1611] SSL Library Error: error:0D0C50A1:asn1 encoding 
routines:ASN1_item_verify:unknown message digest algorithm
[ssl:info] [pid 1611] SSL Library Error: error:14089086:SSL 
routines:ssl3_get_client_certificate:certificate verify failed
[ssl:info] [pid 1611] [client xx.xx.31.200:47576] AH01998: Connection closed to 
child 3 with abortive shutdown


It fails across several phone vendors.

Any suggestions greatly received, thanks in advance

Stuart




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

[openssl-users] How to load the right engine?

[Blumenthal, Uri - 0553 - MITLL]

I’m debugging programmatic access to a (modified) pkcs11 engine. My system has 
several OpenSSL installations: Apple-provided OpenSSL-0.9.8 (kept as that came 
with the OS :), Macports-installed OpenSSL-1.0.2l (the main one installed to 
/opt/local, used by everything Macports builds, and what I use mostly for my 
software), and a couple of OpenSSL-1.1.x installations mostly used for 
debugging.

 

Libp11 is installed in /opt/local/lib/engines, and that version is built 
for/compatible with OpenSSL-1.0.2.

 

There’s an installation of OpenSSL-1.1.0-stable in ~/openssl-1.1. libp11 built 
for 1.1 is installed in ~/openssl-1.1/lib/engines-1.1 directory. So far so good.

 

The problem I’m having now is – my application appears to be getting the wrong 
pkcs11 engine (the one for 1.0.2), based on the error message I get on 
decrypting, which is indicative of the unmodified libp11 version (not the one 
I’m working with for 1.1).

 

Question: how do I ensure/verify that the right pkcs11 library is loaded?

 

Tail of openssl.cnf:

 

[pkcs11_section]

   engine_id = pkcs11

   dynamic_path = /Users/ur20980/openssl-1.1/lib/engines-1.1/pkcs11.dylib

   MODULE_PATH = /usr/local/lib/yubihsm_pkcs11.dylib

   init = 0

 

 

Thanks!

--

Regards,

Uri Blumenthal



smime.p7s
Description: S/MIME cryptographic signature
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] How to increase the priority of some cipher ?

[Jakob Bohm]

Obviously, the DH Ephemeral ciphersuites consist of a (sometimes
fast) DH step PLUS an RSA or ECDSA step to confirm the identity of
the server, while the slightly less secure RSA suites only do the
RSA step.  DH+ECDSA requires an ECDSA certificate, which won't
work for clients that require RSA suites.

On 26/09/2017 18:58, Benjamin Kaduk via openssl-users wrote:
I am curious about this statement that "(EC)DHE cost much more 
resources than RSA".  In particular, ECDHE is supposed to be less 
computation-intensive than RSA for a given security level, so it would 
be interesting to hear what your setup is where the reverse is 
supposed to be observed.


-Ben

On 09/26/2017 03:44 AM, 李明 wrote:

just find it,
 server respect client's cipher preference  by default,
 it selects the suite preferred by client among the cipherlist that 
both the client and server support.
 so it's not enough to just increase RSA cipher priority on server 
side ,
SSL_OP_CIPHER_SERVER_PREFERENCE will make the server select the suite 
that itself most prefer among the cipherlist that both the client and 
server support.



在 2017-09-26 15:15:10，"李明"  写道：

Hello,
   Currently, openssl prefer (EC)DHE handshakes over plain RSA,
but (EC)DHE cost much more resouces than RSA.
   In order to get higher performance , I want to prioritize
RSA related ciphers, does anyone knows how to do it.
   I have tried cipherlist "RSA:ALL:!COMPLEMENTOFDEFAULT:!eNULL"
, it looks fine in openssl command line
./openssl ciphers -v 'RSA:ALL:!COMPLEMENTOFDEFAULT:!eNULL'
AES256-GCM-SHA384      TLSv1.2 Kx=RSA      Au=RSA 
Enc=AESGCM(256) Mac=AEAD
AES128-GCM-SHA256      TLSv1.2 Kx=RSA      Au=RSA 
Enc=AESGCM(128) Mac=AEAD
AES256-SHA256          TLSv1.2 Kx=RSA      Au=RSA  Enc=AES(256)
Mac=SHA256
AES128-SHA256          TLSv1.2 Kx=RSA      Au=RSA  Enc=AES(128)
Mac=SHA256
AES256-SHA             SSLv3 Kx=RSA      Au=RSA  Enc=AES(256)
Mac=SHA1
AES128-SHA             SSLv3 Kx=RSA      Au=RSA  Enc=AES(128)
Mac=SHA1
ECDHE-ECDSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH     Au=ECDSA
Enc=AESGCM(256) Mac=AEAD

 but, after SSL_CTX_set_cipher_list(ctx,
"RSA:ALL:!COMPLEMENTOFDEFAULT:!eNULL")  in my application, it
didn't work, the first choice is still ECDHE-RSA-AES256-GCM-SHA384


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

Re: [openssl-users] How to emulate EVP_PKEY_meth_get_sign() on OpenSSL-1.0.2?

[Salz, Rich via openssl-users]

Ø  Is there a way to emulate the above calls, and achieve similar result on 
OpenSSL-1.0.2?

Just pull the fields out of the struct directly?
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

[openssl-users] How to emulate EVP_PKEY_meth_get_sign() on OpenSSL-1.0.2?

[Blumenthal, Uri - 0553 - MITLL]

An engine works with OpenSSL-1.1.0+. It needs to hook some methods, and it 
accesses them via EVP_PKEY_meth_get_sign(), EVP_PKEY_meth_get_decrypt(), and 
EVP_PKEY_meth_get_encrypt(). And the corresponding set() calls.

 

I’d like to backport this engine to OpenSSL-1.0.2. But 1.0.2 does not provide 
these calls.

 

Is there a way to emulate the above calls, and achieve similar result on 
OpenSSL-1.0.2? 

 

Thanks!

--

Regards,

Uri Blumenthal



smime.p7s
Description: S/MIME cryptographic signature
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] How to increase the priority of some cipher ?

[Benjamin Kaduk via openssl-users]

I am curious about this statement that "(EC)DHE cost much more resources
than RSA".  In particular, ECDHE is supposed to be less
computation-intensive than RSA for a given security level, so it would
be interesting to hear what your setup is where the reverse is supposed
to be observed.

-Ben

On 09/26/2017 03:44 AM, 李明 wrote:
> just find it, 
>  server respect client's cipher preference  by default,  
>  it selects the suite preferred by client among the cipherlist that
> both the client and server support.
>  so it's not enough to just increase RSA cipher priority on server
> side ,  
>  SSL_OP_CIPHER_SERVER_PREFERENCE will make the server select the suite
> that itself most prefer among the cipherlist that both the client and
> server support.
>
>
> 在 2017-09-26 15:15:10，"李明"  写道：
>
> Hello, 
>    Currently, openssl prefer (EC)DHE handshakes over plain RSA,
> but (EC)DHE cost much more resouces than RSA.
>    In order to get higher performance , I want to  prioritize
> RSA related ciphers, does anyone knows how to do it.
>    
>    I have tried cipherlist "RSA:ALL:!COMPLEMENTOFDEFAULT:!eNULL" ,
> it looks fine in openssl command line
>    ./openssl ciphers -v 'RSA:ALL:!COMPLEMENTOFDEFAULT:!eNULL' 
> AES256-GCM-SHA384       TLSv1.2 Kx=RSA      Au=RSA 
> Enc=AESGCM(256) Mac=AEAD
> AES128-GCM-SHA256       TLSv1.2 Kx=RSA      Au=RSA 
> Enc=AESGCM(128) Mac=AEAD
> AES256-SHA256           TLSv1.2 Kx=RSA      Au=RSA  Enc=AES(256) 
> Mac=SHA256
> AES128-SHA256           TLSv1.2 Kx=RSA      Au=RSA  Enc=AES(128) 
> Mac=SHA256
> AES256-SHA              SSLv3 Kx=RSA      Au=RSA  Enc=AES(256) 
> Mac=SHA1
> AES128-SHA              SSLv3 Kx=RSA      Au=RSA  Enc=AES(128) 
> Mac=SHA1
> ECDHE-ECDSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH     Au=ECDSA
> Enc=AESGCM(256) Mac=AEAD
>
>  but, after SSL_CTX_set_cipher_list(ctx,
> "RSA:ALL:!COMPLEMENTOFDEFAULT:!eNULL")  in my application, it
> didn't work, the first choice is still ECDHE-RSA-AES256-GCM-SHA384
>
>
> 【网易自营】好吃到爆！鲜香弹滑加热即食，经典13香/麻辣小龙虾仅75元3斤>>
>  
> 
> 
>    
>
>
>
> 【网易自营|30天无忧退货】仅售同款价1/4！MUJI制造商“2017秋冬舒适家居拖鞋系列”限时仅34.9元>>
>  
> 
>    
>
>

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

Re: [openssl-users] Hardware client certificates moving to Centos 7

[Stuart Marsden]

Sorry how can I tell ?

I can run a wireshark if necessary

thanks


> On 26 Sep 2017, at 16:36, Wouter Verhelst  wrote:
> 
> On 26-09-17 17:26, Stuart Marsden wrote:
>> [ssl:info] [pid 1611] SSL Library Error: error:0D0C50A1:asn1 encoding 
>> routines:ASN1_item_verify:unknown message digest algorithm
> 
> So which message digest algorithm is the client trying to use?
> 
> -- 
> Wouter Verhelst
> -- 
> 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] Hardware client certificates moving to Centos 7

[Wouter Verhelst]

On 26-09-17 17:26, Stuart Marsden wrote:
> [ssl:info] [pid 1611] SSL Library Error: error:0D0C50A1:asn1 encoding 
> routines:ASN1_item_verify:unknown message digest algorithm

So which message digest algorithm is the client trying to use?

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

[openssl-users] Hardware client certificates moving to Centos 7

[Stuart Marsden]

Hi

I have Centos/Apache servers for securely provisioning IP phones using hardware 
client certificates embedded in the phones.

for this test I have allowed all protocols and ciphers

on Centos 6 this works fine, the rpms are:

openssl098e-0.9.8e-20.el6.centos.1.x86_64
openssl-1.0.1e-57.el6.x86_64
openssl-devel-1.0.1e-57.el6.x86_64

on centos 7 the rpms are:

openssl098e-0.9.8e-29.el7.centos.3.x86_64
openssl-1.0.2k-8.el7.x86_64
openssl-libs-1.0.2k-8.el7.x86_64
xmlsec1-openssl-1.2.20-7.el7_4.x86_64
openssl-devel-1.0.2k-8.el7.x86_64

on Centos 7 the logging with "Loglevel debug"  in the apache config file is a 
lot less than Centos 6


The SSL fails to establish with the error below:


ssl_engine_kernel.c(1890): [client XX.XX.31.200:47576] AH02043: SSL virtual 
host for servername  found

ssl_engine_kernel.c(1360): [client XX.XX.31.200:47576] AH02275: Certificate 
Verification, depth 1, CRL checking mode: none [subject: 
emailAddress=supp...@yealink.com,CN=Yealink Equipment Issuing 
CA,OU=yealink.com,O=Yealink Network Technology 
Co.\\,Ltd.,L=Xiamen,ST=Fujian,C=CN / issuer: 
emailAddress=supp...@yealink.com,CN=Yealink Equipment Issuing 
CA,OU=yealink.com,O=Yealink Network Technology 
Co.\\,Ltd.,L=Xiamen,ST=Fujian,C=CN / serial: E17F3D266C47321E / notbefore: Nov  
7 12:45:52 2013 GMT / notafter: Nov  7 12:45:52 2033 GMT]

ssl_engine_kernel.c(1360): [client xx.xx.31.200:47576] AH02275: Certificate 
Verification, depth 0, CRL checking mode: none [subject: 
emailAddress=supp...@yealink.com,CN=001565c8be6f,OU=Yealink Equipment,O=Yealink 
Network Technology Co.\\,Ltd.,L=Xiamen,ST=Fujian,C=CN / issuer: 
emailAddress=supp...@yealink.com,CN=Yealink Equipment Issuing 
CA,OU=yealink.com,O=Yealink Network Technology 
Co.\\,Ltd.,L=Xiamen,ST=Fujian,C=CN / serial: 303031353635633862653666 / 
notbefore: Mar  1 00:00:00 2014 GMT / notafter: Feb 24 00:00:00 2034 GMT]

[ssl:info] [pid 1611] [client xx.xx.31.200:47576] AH02276: Certificate 
Verification: Error (7): certificate signature failure [subject: 
emailAddress=supp...@yealink.com,CN=001565c8be6f,OU=Yealink Equipment,O=Yealink 
Network Technology Co.\\,Ltd.,L=Xiamen,ST=Fujian,C=CN / issuer: 
emailAddress=supp...@yealink.com,CN=Yealink Equipment Issuing 
CA,OU=yealink.com,O=Yealink Network Technology 
Co.\\,Ltd.,L=Xiamen,ST=Fujian,C=CN / serial: 303031353635633862653666 / 
notbefore: Mar  1 00:00:00 2014 GMT / notafter: Feb 24 00:00:00 2034 GMT]

[ssl:info] [pid 1611] [client xx.xx.31.200:47576] AH02008: SSL library error 1 
in handshake (server xxx.xxx.xxx.xxx:443)
[ssl:info] [pid 1611] SSL Library Error: error:0D0C50A1:asn1 encoding 
routines:ASN1_item_verify:unknown message digest algorithm
[ssl:info] [pid 1611] SSL Library Error: error:14089086:SSL 
routines:ssl3_get_client_certificate:certificate verify failed
[ssl:info] [pid 1611] [client xx.xx.31.200:47576] AH01998: Connection closed to 
child 3 with abortive shutdown


It fails across several phone vendors.

Any suggestions greatly received, thanks in advance

Stuart


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

Re: [openssl-users] How can I sstart openssl ocsp in secure mode using TLS/SSL

[Michael Wojcik]

> From: openssl-users [mailto:openssl-users-boun...@openssl.org] On Behalf Of 
> Richard Moore
> Sent: Tuesday, September 26, 2017 06:31
> To: openssl-users@openssl.org
> Subject: Re: [openssl-users] How can I sstart openssl ocsp in secure mode 
> using TLS/SSL

​​> The CA Security Council and CA/Browser Forum are unrelated organisations.​

True, but CASC endorses CA/BF, for example by requiring its members meet the 
CA/BF Basic Requirements. They may be "unrelated" but they're quite chummy.

That said, I don't think openssl-users is an ideal, or effective, forum for 
organizing an escape from the CA/BF cabal. That will have to happen elsewhere, 
if it's to happen at all.

-- 
Michael Wojcik 
Distinguished Engineer, Micro Focus 


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

Re: [openssl-users] How can I sstart openssl ocsp in secure mode using TLS/SSL

[Jakob Bohm]

On 26/09/2017 14:31, Richard Moore wrote:



On 26 September 2017 at 02:36, Kyle Hamilton > wrote:


On Fri, Sep 22, 2017 at 9:32 AM, Richard Moore
> wrote:
>
> It's also worth pointing out that CAs are banned from running
OCSP servers over HTTPS anyway and it isn't needed since the
responses are already signed - http is fine.

That argument fails when you consider that some people want the
details of who they're talking to or asking about to be confidential,
not merely authentic.


​That doesn't change the fact it's banned.​


But ONLY for CAB/F regulated public CAs.


I'm a believer in the idea that SNI and the Certificate messages
should happen under an ephemeral DH or ephemeral ECDH cover.  Others
fear-monger to say "maybe they shouldn't".


​There are a lot of other things that would also need addressing to 
make it secret /who/ you're talking to. ​It's not something https 
guarantees right now. If you'd like it to that would be a whole other 
discussion.



However wiretapping a few central non-https OCSP responders is one
of the few attacks that will reveal this without wiretapping the
actual connection.

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

Re: [openssl-users] How can I sstart openssl ocsp in secure mode using TLS/SSL

[Richard Moore]

On 26 September 2017 at 02:36, Kyle Hamilton  wrote:

> On Fri, Sep 22, 2017 at 9:32 AM, Richard Moore 
> wrote:
> >
> > It's also worth pointing out that CAs are banned from running OCSP
> servers over HTTPS anyway and it isn't needed since the responses are
> already signed - http is fine.
>
> That argument fails when you consider that some people want the
> details of who they're talking to or asking about to be confidential,
> not merely authentic.
>
>
​That doesn't change the fact it's banned.​



> I'm a believer in the idea that SNI and the Certificate messages
> should happen under an ephemeral DH or ephemeral ECDH cover.  Others
> fear-monger to say "maybe they shouldn't".
>
>
​There are a lot of other things that would also need addressing to make it
secret /who/ you're talking to. ​It's not something https guarantees right
now. If you'd like it to that would be a whole other discussion.



> (Also, for completeness, the argument that "CAs are banned from
> running OCSP servers over HTTPS anyway" is a straw man at best -- not
> every CA is created or intends to be a member of or subject to the
> mandates of the CA Security Council, formerly known as the CA/Browser
> Forum.  And every attempt to encode policy into technical standards,
>

​​The CA Security Council and CA/Browser Forum are unrelated organisations.​

Regards

Rich.


> attempting to prohibit certain actions for whatever misguided
> administrative reasons, is subject to being bypassed by people who
> understand the various parts and how to glue them all together.)
>
To be fair, the OCSP responder certificate may or may not be
> revoked... but honestly, if you're asking the OCSP responder for the
> status of its own certificate you're opening yourself up to a
> subordination/subversion attack anyway.  OCSP responders should have
> very short-lived certificates, to minimize the temporal subordination
> attack surface.
>

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

Re: [openssl-users] Manually shutdown the library

[Salz, Rich via openssl-users]

The original issue was discussed here:  
https://www.mail-archive.com/openssl-users@openssl.org/msg80781.html


There are no plans to do so.  You’ll have to modify the source and/or make a 
pull request.
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

[openssl-users] [ANN] M2Crypto 0.26.4

[Matěj Cepl]

One more bugfix release, fixing one silly FTBFS presenting itself on
systems with OpenSSL 1.1.0 and LibreSSL (if anybody can provide some
testing experience with LibreSSL and file bugs at
https://gitlab.com/m2crypto/m2crypto/issues it would be very helpful).

I am sorry,

Matěj

-- 
https://matej.ceplovi.cz/blog/, Jabber: mc...@ceplovi.cz
GPG Finger: 3C76 A027 CA45 AD70 98B5  BC1D 7920 5802 880B C9D8

Quod fuimus, estis; quod sumus, vos eritis.





signature.asc
Description: OpenPGP digital signature
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] How to increase the priority of some cipher ?

[李明]

just find it, 
 server respect client's cipher preference  by default,  
 it selects the suite preferred by client among the cipherlist that both the 
client and server support.
 so it's not enough to just increase RSA cipher priority on server side ,  
 SSL_OP_CIPHER_SERVER_PREFERENCE will make the server select the suite that 
itself most prefer among the cipherlist that both the client and server support.



在 2017-09-26 15:15:10，"李明"  写道：

Hello, 
   Currently, openssl prefer (EC)DHE handshakes over plain RSA, but (EC)DHE 
cost much more resouces than RSA.
   In order to get higher performance , I want to  prioritize RSA related 
ciphers, does anyone knows how to do it.
   
   I have tried cipherlist "RSA:ALL:!COMPLEMENTOFDEFAULT:!eNULL" , it looks 
fine in openssl command line
   ./openssl ciphers -v 'RSA:ALL:!COMPLEMENTOFDEFAULT:!eNULL' 
AES256-GCM-SHA384   TLSv1.2 Kx=RSA  Au=RSA  Enc=AESGCM(256) Mac=AEAD
AES128-GCM-SHA256   TLSv1.2 Kx=RSA  Au=RSA  Enc=AESGCM(128) Mac=AEAD
AES256-SHA256   TLSv1.2 Kx=RSA  Au=RSA  Enc=AES(256)  Mac=SHA256
AES128-SHA256   TLSv1.2 Kx=RSA  Au=RSA  Enc=AES(128)  Mac=SHA256
AES256-SHA  SSLv3 Kx=RSA  Au=RSA  Enc=AES(256)  Mac=SHA1
AES128-SHA  SSLv3 Kx=RSA  Au=RSA  Enc=AES(128)  Mac=SHA1
ECDHE-ECDSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH Au=ECDSA Enc=AESGCM(256) 
Mac=AEAD


 but, after SSL_CTX_set_cipher_list(ctx, "RSA:ALL:!COMPLEMENTOFDEFAULT:!eNULL") 
 in my application, it didn't work, the first choice is still 
ECDHE-RSA-AES256-GCM-SHA384



【网易自营】好吃到爆！鲜香弹滑加热即食，经典13香/麻辣小龙虾仅75元3斤>>  -- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

[openssl-users] How to increase the priority of some cipher ?

[李明]

Hello, 
   Currently, openssl prefer (EC)DHE handshakes over plain RSA, but (EC)DHE 
cost much more resouces than RSA.
   In order to get higher performance , I want to  prioritize RSA related 
ciphers, does anyone knows how to do it.
   
   I have tried cipherlist "RSA:ALL:!COMPLEMENTOFDEFAULT:!eNULL" , it looks 
fine in openssl command line
   ./openssl ciphers -v 'RSA:ALL:!COMPLEMENTOFDEFAULT:!eNULL' 
AES256-GCM-SHA384   TLSv1.2 Kx=RSA  Au=RSA  Enc=AESGCM(256) Mac=AEAD
AES128-GCM-SHA256   TLSv1.2 Kx=RSA  Au=RSA  Enc=AESGCM(128) Mac=AEAD
AES256-SHA256   TLSv1.2 Kx=RSA  Au=RSA  Enc=AES(256)  Mac=SHA256
AES128-SHA256   TLSv1.2 Kx=RSA  Au=RSA  Enc=AES(128)  Mac=SHA256
AES256-SHA  SSLv3 Kx=RSA  Au=RSA  Enc=AES(256)  Mac=SHA1
AES128-SHA  SSLv3 Kx=RSA  Au=RSA  Enc=AES(128)  Mac=SHA1
ECDHE-ECDSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH Au=ECDSA Enc=AESGCM(256) 
Mac=AEAD


 but, after SSL_CTX_set_cipher_list(ctx, "RSA:ALL:!COMPLEMENTOFDEFAULT:!eNULL") 
 in my application, it didn't work, the first choice is still 
ECDHE-RSA-AES256-GCM-SHA384-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users