Re: SSL_set_fd() and fd type in Windows 64
We get such types of warning while doing compilation for x64 environment,
but normally don't face any problem during run-time.
Thanks,
PK
On Tue, Nov 5, 2013 at 6:36 AM, wrote:
> On Windows, sockets and filedescriptors are HANDLES which are pointers.
>
> This is all nice and fine on 32bit Windows.
>
> However on 64bit windows int is 32bits and HANDLE is a 64bit pointer,
> leading to following warning:
>
> warning: cast from pointer to integer of different size
> [-Wpointer-to-int-cast]
> if (!SSL_set_fd(bu->ssl, (int)bu->fd)) {
>
> Is this something to worry about?
>
> The platform is mingw-w64.
>
> Cheers,
> --Sampo
> __
> OpenSSL Project http://www.openssl.org
> User Support Mailing Listopenssl-users@openssl.org
> Automated List Manager majord...@openssl.org
>
SSL_set_fd() and fd type in Windows 64
On Windows, sockets and filedescriptors are HANDLES which are pointers.
This is all nice and fine on 32bit Windows.
However on 64bit windows int is 32bits and HANDLE is a 64bit pointer,
leading to following warning:
warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
if (!SSL_set_fd(bu->ssl, (int)bu->fd)) {
Is this something to worry about?
The platform is mingw-w64.
Cheers,
--Sampo
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager majord...@openssl.org
RE: SSL/TLS encryption algorithms
> From: owner-openssl-users On Behalf Of Viktor Dukhovni > Sent: Friday, November 01, 2013 18:12 > > > $ openssl ciphers -v DHE-RSA-CAMELLIA256-SHA > > > DHE-RSA-CAMELLIA256-SHA SSLv3 Kx=DH Au=RSA > Enc=Camellia(256) Mac=SHA1 > > > > > > $ openssl ciphers -v AES128-SHA256 > > > AES128-SHA256 TLSv1.2 Kx=RSA Au=RSA Enc=AES(128) > Mac=SHA256 > > > > > >Does your application need to perform faster, offer forward-secrecy, be > > >most interoperable, ... ? > > > > these was the result of using 2 different browsers with the same SSL > > website ... > > (1) an old firefox > > (2) the latest IE - IE11 on Win 8.1 > > Different browsers (or sometimes versions) offer different lists of supported cipher suites, in different orders. In some cases the same browser can be reconfigured to offer different suites; Firefox in particular can do this in about:config. I don't know about Windows/IE but it wouldn't surprise me at all if there's a registry hack. Some servers, and particularly OpenSSL and thus Apache by default (unless you configure HonorCipherOrder), will agree the first suite in client preference order that the server supports. In practice this tends to be the first one, or in the first few, of the client preferences. Firefox is the only client I know that prefers Camellia to AES at same strength, and thus tends to get a Camellia suite from a server that supports them, as OpenSSL and thus Apache do unless disabled. > > https://ssl.mathemainzel.info/info/ > > you can try your browser ... > > > > how would I define forward-secrecy on Apache webserver? > > If the server negotiated both ciphers, it already supports > forward-secrecy (aka PFS) if the client does too. > Not necessarily. In principle either end could implement and be configured to support each PFS suite individually; even if both ends support some PFS suite or suites, they may not intersect and allow actual PFS session. In practice this mostly breaks down by auth&kx; there would be no sensible reason to exclude an implementable suite that is otherwise strong enough. In particular IE/Windows through the latest I have (IE9/Seven) supports DHE-DSS but not DHE-RSA. If an OpenSSL server has RSA key&cert, and dh_tmp but not ecdh_tmp params, it supports DHE-RSA but not DHE-DSS. That means both ends "support" PFS, but they still can't negotiate it. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
RE: Signature Algorithm that was disabled because that algorithm is not secure
> From: owner-openssl-users On Behalf Of Marcus Schmitt > Sent: Monday, November 04, 2013 10:31 > I created the root-CA, Intermediate-CA and the servercert on my MAC > (10.8), afterwards I imported the file to my FreeBSD 9. > > When I try to create all the CA and certs on my FreeBSD directly I receive the > following error: > > === > openssl req -new -x509 -nodes -days 3650 -key private/cakey.pem -out > certs/cacert.pem -config openssl.cnf > > Error Loading request extension section v3_req > 11827:error:22071071:X509 V3 routines:string_to_hex:illegal hex > digit:/usr/src/secure/lib/libcrypto/../../../crypto/openssl/crypto/x509v3/v3 _ > utl.c:441: > 11827:error:22098080:X509 V3 routines:X509V3_EXT_nconf:error in > extension:/usr/src/secure/lib/libcrypto/../../../crypto/openssl/crypto/x509v > 3/v3_conf.c:93:name=subjectKeyIdentifier, value=hasH > === > > Could the issue be caused by the MAC ? > What might be the reason for this issue ? > Look carefully at the error message; you have subjectKeyIdentifier=hasH with an uppercase H when it should be lowercase. Did you "import" the openssl.cnf file and if so how? ftp, rcp, scp, smb, USB, etc? Or did you retype it? If you retype, some things including this must be exact. Mac OSX (and earlier) *filenames* are (at least usually) case-insensitive, but AFAIK no Macs ever ignored case for entering or changing text *in* a file. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Signature Algorithm that was disabled because that algorithm is not secure
Hello, there is one information I forgot to mention in my previews mails, maybe this is the reason for the problem. I created the root-CA, Intermediate-CA and the servercert on my MAC (10.8), afterwards I imported the file to my FreeBSD 9. When I try to create all the CA and certs on my FreeBSD directly I receive the following error: === openssl req -new -x509 -nodes -days 3650 -key private/cakey.pem -out certs/cacert.pem -config openssl.cnf Error Loading request extension section v3_req 11827:error:22071071:X509 V3 routines:string_to_hex:illegal hex digit:/usr/src/secure/lib/libcrypto/../../../crypto/openssl/crypto/x509v3/v3_utl.c:441: 11827:error:22098080:X509 V3 routines:X509V3_EXT_nconf:error in extension:/usr/src/secure/lib/libcrypto/../../../crypto/openssl/crypto/x509v3/v3_conf.c:93:name=subjectKeyIdentifier, value=hasH === Could the issue be caused by the MAC ? What might be the reason for this issue ? Best Regards Marcus Am 30.10.2013 um 19:26 schrieb Marcus Schmitt : > Hello Walter, > > the problem is that the openssl.cnf file already include this line: > > This is my file: > > === > # OpenSSL configuration file. > # > > # Establish working directory. > > dir = . > > [ ca ] > default_ca = CA_default > > [ CA_default ] > serial = $dir/serial > database= $dir/certindex.txt > new_certs_dir = $dir/certs > certificate = $dir/cacert.pem > private_key = $dir/private/cakey.pem > default_days= 365 > default_md = sha1 > preserve= no > email_in_dn = no > nameopt = default_ca > certopt = default_ca > policy = policy_match > > [ policy_match ] > countryName = match > stateOrProvinceName = match > organizationName= match > organizationalUnitName = optional > commonName = supplied > emailAddress= optional > > [ req ] > default_bits= 2048 # Size of keys > default_keyfile = key.pem # name of > generated keys > default_md = sha1 # message > digest algorithm > string_mask = nombstr # permitted > characters > distinguished_name = req_distinguished_name > req_extensions = v3_req > > [ req_distinguished_name ] > # Variable name Prompt string > #--- > 0.organizationName = Organization Name (company) > organizationalUnitName = Organizational Unit Name > (department, division) > emailAddress= Email Address > emailAddress_max= 40 > localityName= Locality Name (city, district) > stateOrProvinceName = State or Province Name (full name) > countryName = Country Name (2 letter code) > countryName_min = 2 > countryName_max = 2 > commonName = Common Name (hostname, IP, or your > name) > commonName_max = 64 > > [ v3_ca ] > basicConstraints= CA:TRUE > subjectKeyIdentifier= hash > authorityKeyIdentifier = issuer:always > > [ v3_req ] > basicConstraints= CA:FALSE > subjectKeyIdentifier= hash > === > > Or is there anything wrong with this file ? > > > Best Regards Marcus > > > > Am 30.10.2013 um 19:05 schrieb Walter H. : > >> Hello, >> >> On 30.10.2013 18:17, Marcus Schmitt wrote: >>> I have one problem after I created a root-CA, intermediate-CA and a server >>> certificate. After I configured my apache with the server cert, key and >>> intermediate cert and importing the root-CA to firefox 24 I received the >>> following error when I browse to the website: >>> >>> Could not verify this certificate because it was signed using a signature >>> algoritm that was disabled because that algorithm is not secure >>> >>> >>> I assume the reason for this error message is that I see "Certificate >>> Signatore Algorithm" is "PKCS #1 MD5 With RSA Encryption" for the >>> Intermediate Certificate and Server Certificate. For the root-CA I see >>> "PKCS #1 SHA With RSA Encryption". >>> >>> Unfortunately I was not able to find the reason for this issue, please find >>>
Re: DTLS PSK in FIPS mode
Awesome, thank you! Can you please help me close bug 3152? I will put in a change request to have TLS1_TXT_PSK_WITH_AES_128_CBC_SHA and TLS1_TXT_PSK_WITH_AES_256_CBC_SHA enabled in FIPS mode. Best regards, Fredrik On Mon, Nov 4, 2013 at 3:37 PM, Dr. Stephen Henson wrote: > On Mon, Nov 04, 2013, Fredrik Jansson wrote: > > > Thanks, that did it! > > > > To try to understand the implications of this, if I add SSL_FIPS > > to TLS1_TXT_PSK_WITH_AES_128_CBC_SHA and > TLS1_TXT_PSK_WITH_AES_256_CBC_SHA, > > am I violating the security policy? AES 128/256 CBC and SHA are approved > > algorithms(?). > > > > The security policy means you cannot modify any code in the validated > module > source, it does not apply to the FIPS capable OpenSSL which is effectively > an > "application" of the FIPS module. > > Steve. > -- > Dr Stephen N. Henson. OpenSSL project core developer. > Commercial tech support now available see: http://www.openssl.org > __ > OpenSSL Project http://www.openssl.org > User Support Mailing Listopenssl-users@openssl.org > Automated List Manager majord...@openssl.org >
Re: DTLS PSK in FIPS mode
On Mon, Nov 04, 2013, Fredrik Jansson wrote: > Thanks, that did it! > > To try to understand the implications of this, if I add SSL_FIPS > to TLS1_TXT_PSK_WITH_AES_128_CBC_SHA and TLS1_TXT_PSK_WITH_AES_256_CBC_SHA, > am I violating the security policy? AES 128/256 CBC and SHA are approved > algorithms(?). > The security policy means you cannot modify any code in the validated module source, it does not apply to the FIPS capable OpenSSL which is effectively an "application" of the FIPS module. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: DTLS PSK in FIPS mode
Thanks, that did it!
To try to understand the implications of this, if I add SSL_FIPS
to TLS1_TXT_PSK_WITH_AES_128_CBC_SHA and TLS1_TXT_PSK_WITH_AES_256_CBC_SHA,
am I violating the security policy? AES 128/256 CBC and SHA are approved
algorithms(?).
Best regards,
Fredrik
On Mon, Nov 4, 2013 at 2:31 PM, Dr. Stephen Henson wrote:
> On Mon, Nov 04, 2013, Fredrik Jansson wrote:
>
> > Steve, thanks for getting back!
> >
> > Since I could not reproduce this using s_client and s_server I set out to
> > take the code I am using into a sample project.
> >
> > Doing so I believe I have found the issue, SSL_CTX_set_cipher(ctx,
> > SSL_TXT_PSK) returns an error ("SSL routines:SSL_CTX_set_cipher_list:no
> > cipher match") if I have called FIPS_mode_set(1) first.
> >
> > My original code did not check the return value of SSL_CTX_set_cipher so
> > that may very well be the cause of the subsequent crash.
> >
> > Now my question becomes why I cannot select SSL_TXT_PSK when in FIPS
> mode?
> >
>
> The ciphersuites supported in FIPS mode are restricted to those which use
> approved algorithms. PSK at present is not listed though there isn't really
> any reason why it can't be included in future.
>
> To test this add the flag SSL_FIPS to the relevant ciphersuits in s3_lib.c
>
> Steve.
> --
> Dr Stephen N. Henson. OpenSSL project core developer.
> Commercial tech support now available see: http://www.openssl.org
> __
> OpenSSL Project http://www.openssl.org
> User Support Mailing Listopenssl-users@openssl.org
> Automated List Manager majord...@openssl.org
>
Re: DTLS PSK in FIPS mode
On Mon, Nov 04, 2013, Fredrik Jansson wrote:
> Steve, thanks for getting back!
>
> Since I could not reproduce this using s_client and s_server I set out to
> take the code I am using into a sample project.
>
> Doing so I believe I have found the issue, SSL_CTX_set_cipher(ctx,
> SSL_TXT_PSK) returns an error ("SSL routines:SSL_CTX_set_cipher_list:no
> cipher match") if I have called FIPS_mode_set(1) first.
>
> My original code did not check the return value of SSL_CTX_set_cipher so
> that may very well be the cause of the subsequent crash.
>
> Now my question becomes why I cannot select SSL_TXT_PSK when in FIPS mode?
>
The ciphersuites supported in FIPS mode are restricted to those which use
approved algorithms. PSK at present is not listed though there isn't really
any reason why it can't be included in future.
To test this add the flag SSL_FIPS to the relevant ciphersuits in s3_lib.c
Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager majord...@openssl.org
Re: DTLS PSK in FIPS mode
Steve, thanks for getting back!
Since I could not reproduce this using s_client and s_server I set out to
take the code I am using into a sample project.
Doing so I believe I have found the issue, SSL_CTX_set_cipher(ctx,
SSL_TXT_PSK) returns an error ("SSL routines:SSL_CTX_set_cipher_list:no
cipher match") if I have called FIPS_mode_set(1) first.
My original code did not check the return value of SSL_CTX_set_cipher so
that may very well be the cause of the subsequent crash.
Now my question becomes why I cannot select SSL_TXT_PSK when in FIPS mode?
Best regards,
Fredrik
On Sun, Nov 3, 2013 at 4:15 PM, Dr. Stephen Henson wrote:
> On Fri, Oct 25, 2013, Fredrik Jansson wrote:
>
> >
> > I am trying to use DTLS with PSK (cipher: SSL_TXT_PSK). Everything works
> > well if I don't set OpenSSL in FIPS mode (FIPS_mode_set(1)).
> >
>
> Can you reproduce this using s_client and s_server? If so can you give
> details
> of the command lines you used?
>
> Steve.
> --
> Dr Stephen N. Henson. OpenSSL project core developer.
> Commercial tech support now available see: http://www.openssl.org
> __
> OpenSSL Project http://www.openssl.org
> User Support Mailing Listopenssl-users@openssl.org
> Automated List Manager majord...@openssl.org
>
