Re: [openssl-users] 2-key vs 3-key 3DES

[Jeffrey Walton]

> I've just been reading about recommended and deprecated encryption and 
> tripped over a nist document 
> (http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-131Ar1.pdf) 
> that distinguishes between 2key and 3key 3DES saying that the former is 
> deprecated after 2015 but the latter is still acceptable.
>
2-key 3DES provides about 80 bits of security, while 3-key 3DES
provides about 112 bits.

> Is this distinguishable in openssl?  I.e. if we negotiate 
> TLS_RSA_WITH_3DES_EDE_CBC_SHA does it always use the 3-key version?
>

TLS cipher suites, like TLS_RSA_WITH_3DES_EDE_CBC_SHA, use the 3-key
version. Also see RFC 5246, https://tools.ietf.org/html/rfc5246, and
the discussion of "Data Encryption Standard" on page 79:

  DES can also be operated in a mode [3DES] where
  three independent keys and three encryptions are
  used for each block of data; this uses 168 bits of key
  (24 bytes in the TLS key generation method) and
  provides the equivalent of 112 bits of security.

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

[openssl-users] Decrypt TCP session

[Lloyd]

Hi,

I have implemented a sample HTTP server/client based on openssl (boost
asio) and able to send the message encrypted. Loaded the key in Wireshark
and able to see the data in plaintext form.

Now I wish to write an application to decrypt the same "tcp session data"
(tcp session data = the output of follow TCP stream option in Wireshark).

what should be the starting point to implement this? does open ssl have
some sample code/application does this?

Any hint is greatly appreciated.

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

Re: [openssl-users] Firefox problems with two way SSL auth

[David Balažic]

Hi!

Tomcat released version 8.0.32 which bundles OpenSSL 1.0.2e (see below)
The issue remains (with the change that now IE can not connect at all,
it complains about some TLS stuff, did not look into it).

Any hints how to tackle this problem are welcome.

Version details (from tomcat startup log):
Loaded APR based Apache Tomcat Native library 1.2.4 using APR version 1.5.1.
OpenSSL successfully initialized (OpenSSL 1.0.2e 3 Dec 2015)

Regards,
David


On 8 January 2016 at 17:02, David Balažic  wrote:
> Hi!
>
> I encounter this issue when using Firefox to access tomcat (that is
> using openssl) with client cert authentication.
>
> After a certain timeout, the web application does not "see" the
> clients certificate in requests.
>
> The problem happens on different operating systems (Window,s Linux)
> and browsers.
>
> I reported it to tomcat and Firefox, with not much response.
>
> There is a simple test case in comment 1 of the tomcat bug (see below).
>
> Could someone assist in finding the cause of the problem?
> I also have pcap traces (somewhere) of working and non working network 
> traffic.
>
>
> Latest tested configuration:
> tomcat 8.0.30, using OpenSSL 1.0.1m 19 Mar 2015
> Firefox 43.0.4
> OS: Windows 7 Pro SP1 64bit
>
> The tomcat bug with much details:
>
> https://bz.apache.org/bugzilla/show_bug.cgi?id=58244
>
> Firefox bug report (not much details):
> https://bugzilla.mozilla.org/show_bug.cgi?id=1231406
>
> Regards,
> David Balažic
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] Decrypt TCP session

[Short, Todd]

Check out ssldump.
--
-Todd Short
// tsh...@akamai.com
// "One if by land, two if by sea, three if by the Internet."

On Feb 12, 2016, at 10:05 AM, Lloyd 
> wrote:

Hi,

I have implemented a sample HTTP server/client based on openssl (boost asio) 
and able to send the message encrypted. Loaded the key in Wireshark and able to 
see the data in plaintext form.

Now I wish to write an application to decrypt the same "tcp session data" (tcp 
session data = the output of follow TCP stream option in Wireshark).

what should be the starting point to implement this? does open ssl have some 
sample code/application does this?

Any hint is greatly appreciated.

Thanks,
  Lloyd

--
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] 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

Re: [openssl-users] regarding SSL security

[R-D intern]

Thank you a lot, Jakob.I understood your answers and am quite satisfied too
that the replies sound conceptually right. But it would be kind on your part
if you answer some questions further.

1. Regarding question 3, I am using openssl 1.0.2e which supports named
curve. Such a question had earlier been asked in this forum which says ,
such a message is only misleading but the certificate works fine. Here is
the below
link:"http://openssl.6102.n7.nabble.com/ECC-Self-Signed-Certificate-td17042.html#a17047".But
I would like the certificate have a clean structure. How can that be done?

2.Regarding question 7, I am working to secure a middleware that will be
deployed in control and monitoring systems, hence there would be know
persons at the client side and  the certificates I am  using are self signed
ones created using openssl 1.0.2e , hence there will be no public CAs . In
such a scenario , how will the CA know that the private  key has been
compromised? If the private key  gets compromised, then even the certificate
can be forged ,then what is the use of CRL?
 Kindly answer. 
Thanks and regards,
Suman Patro




--
View this message in context: 
http://openssl.6102.n7.nabble.com/regarding-SSL-security-tp63504p63567.html
Sent from the OpenSSL - User mailing list archive at Nabble.com.
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] no version information available error

[cloud force]

Thanks Jakob for the detailed info.

On Thu, Feb 11, 2016 at 7:50 AM, Jakob Bohm  wrote:

> On 10/02/2016 22:46, cloud force wrote:
>
>> Hi Everyone,
>>
>> I installed the FIPS capable openssl library (which was built by myself)
>> on my Ubuntu linux box.
>>
>> For some reason, I keep running into the following errors whenever I run
>> ssh related command:
>>
>>
>> ssh: /lib/x86_64-linux-gnu/libcrypto.so.1.0.0: no version
>> information available (required by ssh)
>>
>>
>> The same error happens when I ran openssl command such as the following:
>>
>> linux-fips@ubuntu:/usr/local/ssl/lib$ openssl ciphers -v | wc -l
>> openssl: /lib/x86_64-linux-gnu/libcrypto.so.1.0.0: no version information
>> available (required by openssl)
>> openssl: /lib/x86_64-linux-gnu/libcrypto.so.1.0.0: no version information
>> available (required by openssl)
>> openssl: /lib/x86_64-linux-gnu/libcrypto.so.1.0.0: no version information
>> available (required by /lib/x86_64-linux-gnu/libssl.so.1.0.0)
>> openssl: /lib/x86_64-linux-gnu/libcrypto.so.1.0.0: no version information
>> available (required by /lib/x86_64-linux-gnu/libssl.so.1.0.0)
>>
>> The Debian-family (includes Ubuntu) standard OpenSSL shared
> libraries is built in a special way to include "version tags"
> in the resulting .so files, and all the openssl-needing
> binaries in Debian/Ubuntu/etc. produce the error message
> above if you install copies of those libraries without those
> extra "version tags".
>
> There are two alternative ways to solve this:
>
> A) Build your FIPS-cabable OpenSSL (not the FIPScanister)
>   with all the extra steps and patches in the Ubuntu OpenSSL
>   source package (.dsc etc.), just adding the FIPS canister.
>Note that some of the patches in the source package are
>   backports of the security fixes included in the latest
>   OpenSSL versions, you'll probably have to figure out the
>   details yourself (unless Kurt Roeckz posts a recipe
>   somewhere).
>
> B) Patch your FIPS-capable OpenSSL makefile (not the
>   FIPScanister makefile) to use a different .so-version, such
>   as .so.1.0.2 .  Then your private openssl build will not be
>   used by the prepackaged software while software explicitly
>   compiled against your locally build OpenSSL will not
>   accidentally pick up the standard non-FIPS OpenSSL.
>
>
>
> 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
>



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

[openssl-users] Validation status of openssl-fips-2.0.11?

[Kyle Hamilton]

I'm not seeing anything about openssl-fips-2.0.11 in
http://csrc.nist.gov/groups/STM/cmvp/documents/140-1/140val-all.htm#1747
, so I'm not quite certain what its validation/certificate status is? 
Also, is a new Security Policy in the works integrating the new HMAC
digests for the new versions of -fips and -fips-ecp?

(Also, would the mandatory HMAC calculation of the original tarball be
okay if it were done using a FIPS-validated version of Mozilla's NSS?)

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

Re: [openssl-users] no version information available error

[Scott Neugroschl]

OpenSSH does not work with the FIPS mode of OpenSSL.  This has been discussed 
both here and on the OpenSSH list.

From: openssl-users [mailto:openssl-users-boun...@openssl.org] On Behalf Of 
cloud force
Sent: Friday, February 12, 2016 11:44 AM
To: openssl-users@openssl.org
Subject: Re: [openssl-users] no version information available error

Thanks Jakob for the detailed info.

On Thu, Feb 11, 2016 at 7:50 AM, Jakob Bohm 
> wrote:
On 10/02/2016 22:46, cloud force wrote:
Hi Everyone,

I installed the FIPS capable openssl library (which was built by myself) on my 
Ubuntu linux box.

For some reason, I keep running into the following errors whenever I run ssh 
related command:


ssh: /lib/x86_64-linux-gnu/libcrypto.so.1.0.0: no version
information available (required by ssh)


The same error happens when I ran openssl command such as the following:

linux-fips@ubuntu:/usr/local/ssl/lib$ openssl ciphers -v | wc -l
openssl: /lib/x86_64-linux-gnu/libcrypto.so.1.0.0: no version information 
available (required by openssl)
openssl: /lib/x86_64-linux-gnu/libcrypto.so.1.0.0: no version information 
available (required by openssl)
openssl: /lib/x86_64-linux-gnu/libcrypto.so.1.0.0: no version information 
available (required by /lib/x86_64-linux-gnu/libssl.so.1.0.0)
openssl: /lib/x86_64-linux-gnu/libcrypto.so.1.0.0: no version information 
available (required by /lib/x86_64-linux-gnu/libssl.so.1.0.0)
The Debian-family (includes Ubuntu) standard OpenSSL shared
libraries is built in a special way to include "version tags"
in the resulting .so files, and all the openssl-needing
binaries in Debian/Ubuntu/etc. produce the error message
above if you install copies of those libraries without those
extra "version tags".

There are two alternative ways to solve this:

A) Build your FIPS-cabable OpenSSL (not the FIPScanister)
  with all the extra steps and patches in the Ubuntu OpenSSL
  source package (.dsc etc.), just adding the FIPS canister.
   Note that some of the patches in the source package are
  backports of the security fixes included in the latest
  OpenSSL versions, you'll probably have to figure out the
  details yourself (unless Kurt Roeckz posts a recipe
  somewhere).

B) Patch your FIPS-capable OpenSSL makefile (not the
  FIPScanister makefile) to use a different .so-version, such
  as .so.1.0.2 .  Then your private openssl build will not be
  used by the prepackaged software while software explicitly
  compiled against your locally build OpenSSL will not
  accidentally pick up the standard non-FIPS OpenSSL.



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



--
Thanks,
Rich

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

Re: [openssl-users] regarding SSL security

[Karl Denninger]

On 2/12/2016 11:37, R-D intern wrote:
> Thank you a lot, Jakob.I understood your answers and am quite satisfied too
> that the replies sound conceptually right. But it would be kind on your part
> if you answer some questions further.
>
> 1. Regarding question 3, I am using openssl 1.0.2e which supports named
> curve. Such a question had earlier been asked in this forum which says ,
> such a message is only misleading but the certificate works fine. Here is
> the below
> link:"http://openssl.6102.n7.nabble.com/ECC-Self-Signed-Certificate-td17042.html#a17047".But
> I would like the certificate have a clean structure. How can that be done?
>
> 2.Regarding question 7, I am working to secure a middleware that will be
> deployed in control and monitoring systems, hence there would be know
> persons at the client side and  the certificates I am  using are self signed
> ones created using openssl 1.0.2e , hence there will be no public CAs . In
> such a scenario , how will the CA know that the private  key has been
> compromised? If the private key  gets compromised, then even the certificate
> can be forged ,then what is the use of CRL?
>  Kindly answer. 
> Thanks and regards,
> Suman Patro
>

If the CA is private then the CA's public certificate (and any
intermediates required to reach it) is loaded into OpenSSL as the chain
of validation.  That certificate can specify an OCSP or CRL location for
revocation checks, which you must then extract and check in your code.

"Best practice" for something of this sort requires that _*both*_ ends
of the connection present and use certificates, not just the server (in
other words you don't want a random client machine connecting either!)
which in turn means you need to check for validity and revocation on
both ends, /*and */you must ensure the security of the CA infrastructure
and its private key.

Note that "how the CA knows the client private key is compromised" is an
/operational /question, not a programmatic one -- as is the case with a
public CA.  (In other words someone has to tell the CA it was stolen so
the CA can issue the revocation, and the application must check that
revocation resource.)

-- 
Karl Denninger
k...@denninger.net 
/The Market Ticker/
/[S/MIME encrypted email preferred]/


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

Re: [openssl-users] Validation status of openssl-fips-2.0.11?

[Steve Marquess]

On 02/12/2016 04:26 PM, Kyle Hamilton wrote:
> I'm not seeing anything about openssl-fips-2.0.11 in
> http://csrc.nist.gov/groups/STM/cmvp/documents/140-1/140val-all.htm#1747
> , so I'm not quite certain what its validation/certificate status is? 

Ok, this is complex, insanely so.

There is one OpenSSL FIPS Module, the "OpenSSL FIPS Object Module v2.0".
It is updated from time to time, to add new platforms, and each revision
of that module is distributed in a tarball with the name
openssl-fips-2.0.N.tar.gz, with N currently at 12. All revisions of the
module are valid; each successive revision by careful design subsumes
all the previously validated platforms.

For a long time this one module had only one validation, #1747. But, we
ran into an intractable issue with the CMVP that meant we were no longer
able to update the #1747 validation[1]. So, we obtained nominally
separate validations for the *same* FIPS module. That one module is now
covered by three separate validations, #1747, #2398, and #2473.

Collectively the three validations include over 120 platforms. One
module, three validations. If you're shipping a product that uses the
OpenSSL FIPS module and need to state which validation number applies,
you need to look to see which of the three validations your platform of
interest is listed for. That is the validation number you reference.

So all three validations are current. The #1747 and #2473 validations
will remain at revision 2.0.10 forever; #1747 because we can't change it
and #2398 so that multi-platform vendors can use the exact same binary
module on the widest range of platforms. New platforms that don't
require source code changes will go on the #2473 validation. New
platforms that require source code changes and thus a new module
revision will of necessity go on the #2398 validation.

Yeah, it's a mess.

> Also, is a new Security Policy in the works integrating the new HMAC
> digests for the new versions of -fips and -fips-ecp?

I don't understand this question.

> (Also, would the mandatory HMAC calculation of the original tarball be
> okay if it were done using a FIPS-validated version of Mozilla's NSS?)

You wouldn't believe how deep that rabbit hole goes. See section 6.6 of
the OpenSSL FIPS user guide
(https://openssl.org/docs/fips/UserGuide-2.0.pdf). The answer to that
question is why we're still snail-mailing CDs (see
http://openssl.com/fips/verify.html).

-Steve M.

[1] A tedious discussion starts at http://openssl.com/fips/hostage.html

-- 
Steve Marquess
OpenSSL Validation Services, Inc.
1829 Mount Ephraim Road
Adamstown, MD  21710
USA
+1 877 673 6775 s/b
+1 301 874 2571 direct
marqu...@openssl.com
gpg/pgp key: http://openssl.com/docs/0x6D1892F5.asc
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

[openssl-users] openssl.ld and global symbols

[cloud force]

Hi Everyone,

I tried to build a FIPS capable OpenSSL Ubuntu package (using the Ubuntu
12.04 debian build scripts).

The Ubuntu package uses Configure for configuring the source tree with the
following parameters:



*ARCH_CONFARGS := enable-ec_nistp_64_gcc_128CONFARGS  = --prefix=/usr
--openssldir=/usr/lib/ssl --libdir=lib/$(DEB_HOST_MULTIARCH) fips no-idea
no-mdc2 no-rc5 zlib  enable-tlsext no-ssl2 $(ARCH_CONFARGS)*


I ran into the following errors near the end of the build:






























*shlib_target=; if [ -n "libcrypto.so.1.0.0 libssl.so.1.0.0" ]; then \
shlib_target="linux-shared"; \elif [ -n "libcrypto" ]; then \
FIPSLD_CC="gcc"; CC=/usr/local/ssl/fips-2.0/bin/fipsld; export CC
FIPSLD_CC; \fi; \LIBRARIES="-L.. -lssl  -L.. -lcrypto" ; \make
-f ../Makefile.shared -e \APPNAME=openssl OBJECTS="openssl.o
verify.o asn1pars.o req.o dgst.o dh.o dhparam.o enc.o passwd.o gendh.o
errstr.o ca.o pkcs7.o crl2p7.o crl.o rsa.o rsautl.o dsa.o dsaparam.o ec.o
ecparam.o x509.o genrsa.o gendsa.o genpkey.o s_server.o s_client.o speed.o
s_time.o apps.o s_cb.o s_socket.o app_rand.o version.o sess_id.o ciphers.o
nseq.o pkcs12.o pkcs8.o pkey.o pkeyparam.o pkeyutl.o spkac.o smime.o cms.o
rand.o engine.o ocsp.o prime.o ts.o srp.o" \LIBDEPS=" $LIBRARIES
-ldl -lz" \link_app.${shlib_target}make[3]: Entering directory
`/home/precise/amd64/openssl/openssl-1.0.1/apps'speed.o: In function
`speed_main':/home/precise/amd64/openssl/openssl-1.0.1/apps/speed.c:1219:
undefined reference to
`private_DES_set_key_unchecked'/home/precise/amd64/openssl/openssl-1.0.1/apps/speed.c:1220:
undefined reference to
`private_DES_set_key_unchecked'/home/precise/amd64/openssl/openssl-1.0.1/apps/speed.c:1221:
undefined reference to
`private_DES_set_key_unchecked'/home/precise/amd64/openssl/openssl-1.0.1/apps/speed.c:1224:
undefined reference to
`private_AES_set_encrypt_key'/home/precise/amd64/openssl/openssl-1.0.1/apps/speed.c:1225:
undefined reference to
`private_AES_set_encrypt_key'/home/precise/amd64/openssl/openssl-1.0.1/apps/speed.c:1226:
undefined reference to
`private_AES_set_encrypt_key'/home/precise/amd64/openssl/openssl-1.0.1/apps/speed.c:1229:
undefined reference to
`private_Camellia_set_key'/home/precise/amd64/openssl/openssl-1.0.1/apps/speed.c:1230:
undefined reference to
`private_Camellia_set_key'/home/precise/amd64/openssl/openssl-1.0.1/apps/speed.c:1231:
undefined reference to
`private_Camellia_set_key'/home/precise/amd64/openssl/openssl-1.0.1/apps/speed.c:1237:
undefined reference to
`private_SEED_set_key'/home/precise/amd64/openssl/openssl-1.0.1/apps/speed.c:1240:
undefined reference to
`private_RC4_set_key'/home/precise/amd64/openssl/openssl-1.0.1/apps/speed.c:1243:
undefined reference to
`private_RC2_set_key'/home/precise/amd64/openssl/openssl-1.0.1/apps/speed.c:1249:
undefined reference to
`private_BF_set_key'/home/precise/amd64/openssl/openssl-1.0.1/apps/speed.c:1252:
undefined reference to `private_CAST_set_key'collect2: ld returned 1 exit
status*


By comparing with the build from the stock tarball, I noticed that the
above symbols were shown as local (t) in libcrypto.so, while they're shown
as global (T) in the libcrypto.so which was built from the stock openssl
tarball. I found that if I add the above symbols to the openssl.ld file,
then the build went through without problems.


My questions are:
1. How was the openssl.ld file generated?

2. Is it an ok solution to add the above symbols to openssl.ld?

3. How to control the symbols visibility in the Makefile so that these
symbols will be exposed as global in the libcrypto.so?



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