Re: [openssl-users] FIPS mode restrictions and DES
From: Steve Marquess marqu...@openssl.com Date: 04/14/15 09:31 and note that of the 101 platforms (OEs) appearing there, most of those operating systems are neither CC certified nor have any other FIPS 140-2 validated crypto. Keep in mind that at Level 1 the validation applies to the cryptographic module, not the calling application that uses that module nor the operating system that runs it. I came across a Red Hat Security Policy document that clearly puts the XFRM out of the Security Policy domain. See section 1.1.2, page 8, in: http://csrc.nist.gov/groups/STM/cmvp/documents/140-1/140sp/140sp1386.pdf This blurs the concept of FIPS validation. Looks more and more that the validation will only care about what is being declared as going for validation. In this case (policy might have changed since 2010) they simply say that no, we do not declare the crypto done via XFRM as part of the Security Policy. And the FIPS lab says, OK, fine. Hmmm Regards. ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] FIPS mode restrictions and DES
On 04/13/2015 01:30 PM, Jakob Bohm wrote: .. With the very unique exception of the OpenSSL FIPS Object Module, there are no FIPS 140-2 validated cryptographic modules that can be obtained in source form and compiled by the end user. The fact that Red Hat (or whomever) has taken open source code and obtained a FIPS 140-2 validation of binaries generated from that code does you no good unless you have those specific binaries, which is to say you're a commercial customer paying for a commercial license from that vendor. Then, even for the OpenSSL FIPS module the validation imposes some pretty perverse constraints (from the usual software engineering perspective). You have to start with a snail-mailed CD, you have to build the binary module in a very special way that will conflict with whatever configuration management you use, etc.; you have to treat it differently that all the other software components of your product. FIPS 140-2 is the tail that wags the dog. -Steve M. Of cause. One point is that if this is a delivery for someone subject to the FIPS-only procurementrequirement imposed on various US Government related entities, then whatever OS theyuse, MUST (by that requirement) have already passed this for its password handling. This is *technically* true, in the narrow sense that supposedly any OS used in DoD should be CC certified and so forth. Should not must. In practice it is very common -- at FIPS 140-2 Level 1 -- for software *products* to use FIPS 140-2 validated crypto on non-certified, non-validated operating systems. Just take a look at Table 2 in the OpenSSL FIPS Object Module Security Policy: http://csrc.nist.gov/groups/STM/cmvp/documents/140-1/140sp/140sp1747.pdf and note that of the 101 platforms (OEs) appearing there, most of those operating systems are neither CC certified nor have any other FIPS 140-2 validated crypto. Keep in mind that at Level 1 the validation applies to the cryptographic module, not the calling application that uses that module nor the operating system that runs it. -Steve M. -- Steve Marquess OpenSSL Software Foundation, Inc. 1829 Mount Ephraim Road Adamstown, MD 21710 USA +1 877 673 6775 s/b +1 301 874 2571 direct marqu...@opensslfoundation.com 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
Re: [openssl-users] OpenSSL 1.0.2 Solaris 32 bit build is broken
Is no-one interested at all about this problem? Or do I need to send it to another place? Regards, John. From: openssl-users [mailto:openssl-users-boun...@openssl.org] On Behalf Of John Unsworth Sent: 10 April 2015 14:54 To: openssl-users@openssl.org Subject: Re: [openssl-users] OpenSSL 1.0.2 Solaris 32 bit build is broken I have compiled 1.0.1m in the same way and that works fine using asm. John. From: openssl-users [mailto:openssl-users-boun...@openssl.org] On Behalf Of John Unsworth Sent: 10 April 2015 12:21 To: openssl-users@openssl.org Subject: [openssl-users] OpenSSL 1.0.2 Solaris 32 bit build is broken I have an application that runs quite happily using OpenSSL 1.0.1h on Solaris 32 bit. I want to upgrade but both 1.0.2 and 1.0.2a cause problems. 1 When building 1.0.2 using ./Configure solaris-sparcv9-cc no-shared -m32 -xcode=pic32 -xldscope=hidden openssl s_client crashes on start: -bash-3.00$ ./openssl s_client -connect eos.es.cpth.ie:4250 Segmentation Fault (core dumped) -bash-3.00$ pstack core core 'core' of 468: ./openssl s_client -connect eos.es.cpth.ie:4250 000e9ce8 sha1_block_data_order (2ed490, 2ed4ec, 4, ffbfebc0, ffbfebc4, 44) + 8 00226140 ssleay_rand_add (ffbfecbc, 1, 20, ffbfeb94, 0, 14) + 530 00227028 RAND_poll (4, ffbfeca8, ffbfecc8, ffbfecc8, 2c0630, 2c0624) + 38c 00226be0 ssleay_rand_status (c734, 0, 2b9f5c, 2c05ac, 2a0e50, 13000) + 138 00065eb4 app_RAND_load_file (ffbfefc0, 2d5218, 1, 2800, 0, 1) + 88 0004d784 s_client_main (0, c00, 0, c00, 2b4adc, 2f4380) + 5c94 0001328c do_cmd (2eb4c8, 3, ffbffa88, 2b4738, 13e64, 2b3e78) + b8 00012f08 main (4, ffbffa84, 2eb4c8, 2a, 2b3e78, 2b4adc) + 3a4 00012a08 _start (0, 0, 0, 0, 0, 2b3e78) + 108 2 So I then rebuilt adding no-asm flag. It manages to connect but negotiation fails with an error: 4280581268:error:140943FC:SSL routines:ssl3_read_bytes:sslv3 alert bad record mac:s3_pkt.c:1456:SSL alert number 20 4280581268:error:140790E5:SSL routines:ssl23_write:ssl handshake failure:s23_lib.c:177: This is against the server that is still running 1.0.1h and can be successfully connected with openssl built with 1.0.1h. Note that the 64 bit build seems to work perfectly. Unfortunately for historical reasons we need to use the 32 bit version. The 32 bit builds that we use on Windows and Linux also work perfectly. Is it something to do with byte order? Regards, John. ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] OpenSSL 1.0.2 Solaris 32 bit build is broken
You could mail it to RT and then it will at least be logged and not forgotten. But no response within four days isn't surprising. ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] FIPS mode restrictions and DES
On 04/14/2015 09:42 AM, jonetsu wrote: From: Steve Marquess marqu...@openssl.com Date: 04/14/15 09:31 and note that of the 101 platforms (OEs) appearing there, most of those operating systems are neither CC certified nor have any other FIPS 140-2 validated crypto. Keep in mind that at Level 1 the validation applies to the cryptographic module, not the calling application that uses that module nor the operating system that runs it. I came across a Red Hat Security Policy document that clearly puts the XFRM out of the Security Policy domain. See section 1.1.2, page 8, in: http://csrc.nist.gov/groups/STM/cmvp/documents/140-1/140sp/140sp1386.pdf This blurs the concept of FIPS validation. Looks more and more that the validation will only care about what is being declared as going for validation. In this case (policy might have changed since 2010) they simply say that no, we do not declare the crypto done via XFRM as part of the Security Policy. And the FIPS lab says, OK, fine. Hmmm No, it doesn't blur anything. That is a Level 1 validation. At Level 1 only the cryptographic module is within scope of the FIPS 140-2 validation. The cryptographic module is a concept that is rather precisely defined in that context. You often hear the term boundary in reference to cryptographic modules. The operating system, and any crypto it may contain, is out of scope == outside the boundary. The calling application(s), and any other crypto it may contain, is out of scope. Any other applications residing on the same system, and any crypto they may contain, are out of scope. The Level 1 validation covers *only* the specific cryptographic module. -Steve M. -- Steve Marquess OpenSSL Software Foundation, Inc. 1829 Mount Ephraim Road Adamstown, MD 21710 USA +1 877 673 6775 s/b +1 301 874 2571 direct marqu...@opensslfoundation.com 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
Re: [openssl-users] DTLS without sockets (or at least an unconnected socket)
On 04/14/2015 09:02 PM, Matt Caswell wrote: On 14/04/15 19:45, Florian Weimer wrote: Is it possible to use DTLS with some sort of non-socket BIO? Basically, I have datagrams which I know belong to a specific DTLS session, and I want to feed them to OpenSSL and get back further datagrams to send out in response. (This is similar to what SSLEngine does in OpenJDK, except there it's for plain TLS.) DTLS currently supports UDP and SCTP for the underlying BIO. In theory you could implement your own BIO to do whatever you want but it would have to support the BIO ctrls that DTLS uses - see crypto/bio/bss_dgram.c (in particular the dgram_ctrl and dgram_sctp_ctrl functions) Interesting. Is this part of the public API? An example how to establish a DTLS session with multiple peers over an unconnected socket would help, too. To do that you need to use DTLSv1_listen(). I recently wrote a man page for this function, but it hasn't hit the repo yet. Attached FYI. Thanks. DTLSv1_listen is very odd because it has a socket address as an “out” parameter, but no socket address length as an “in/out” argument. It doesn't seem very transport-agnostic, either. -- Florian Weimer / Red Hat Product Security ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] DTLS without sockets (or at least an unconnected socket)
On 14/04/15 19:45, Florian Weimer wrote: Is it possible to use DTLS with some sort of non-socket BIO? Basically, I have datagrams which I know belong to a specific DTLS session, and I want to feed them to OpenSSL and get back further datagrams to send out in response. (This is similar to what SSLEngine does in OpenJDK, except there it's for plain TLS.) DTLS currently supports UDP and SCTP for the underlying BIO. In theory you could implement your own BIO to do whatever you want but it would have to support the BIO ctrls that DTLS uses - see crypto/bio/bss_dgram.c (in particular the dgram_ctrl and dgram_sctp_ctrl functions) An example how to establish a DTLS session with multiple peers over an unconnected socket would help, too. To do that you need to use DTLSv1_listen(). I recently wrote a man page for this function, but it hasn't hit the repo yet. Attached FYI. You might also want to check this page: http://sctp.fh-muenster.de/index.html Matt DTLSv1_listen.pod Description: Perl program ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
[openssl-users] DTLS without sockets (or at least an unconnected socket)
Is it possible to use DTLS with some sort of non-socket BIO? Basically, I have datagrams which I know belong to a specific DTLS session, and I want to feed them to OpenSSL and get back further datagrams to send out in response. (This is similar to what SSLEngine does in OpenJDK, except there it's for plain TLS.) An example how to establish a DTLS session with multiple peers over an unconnected socket would help, too. -- Florian Weimer / Red Hat Product Security ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] FIPS mode restrictions and DES
Two things to consider with IPSec: key exchange mechanisms as provided by packages like StrongSwan, and the actual encryption/authentication of packets that is typically being done by the kernel stack and I believe is based on the Kernel Crypto API. So I believe to do IPSec you do need both crypto libraries to be FIPS-validated, perhaps as separate crypto modules. Kevin On Tue, Apr 14, 2015 at 8:51 AM, jonetsu jone...@teksavvy.com wrote: Salz, Rich wrote As the old joke goes, if you have to ask, you can't afford it. Well, exploration can be free. I noticed that Strongswan uses a plug-in architecture for crypto that seemingly allows the use of OpenSSL instead of the kernel for crypto operations, for use under FIPS. Does anyone have an idea of the order of magnitude in performance loss this could be for IPSec, to use crypto from OpenSSL instead of the kernel ? Regards. -- View this message in context: http://openssl.6102.n7.nabble.com/openssl-users-FIPS-mode-restrictions-and-DES-tp57497p57541.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 ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] DTLS without sockets (or at least an unconnected socket)
On 14/04/15 20:24, Florian Weimer wrote: On 04/14/2015 09:02 PM, Matt Caswell wrote: On 14/04/15 19:45, Florian Weimer wrote: Is it possible to use DTLS with some sort of non-socket BIO? Basically, I have datagrams which I know belong to a specific DTLS session, and I want to feed them to OpenSSL and get back further datagrams to send out in response. (This is similar to what SSLEngine does in OpenJDK, except there it's for plain TLS.) DTLS currently supports UDP and SCTP for the underlying BIO. In theory you could implement your own BIO to do whatever you want but it would have to support the BIO ctrls that DTLS uses - see crypto/bio/bss_dgram.c (in particular the dgram_ctrl and dgram_sctp_ctrl functions) Interesting. Is this part of the public API? Yes. To write your own BIO you would need to create a custom BIO_METHOD which is defined in bio.h. All of the various ctrls are also defined in bio.h. An example how to establish a DTLS session with multiple peers over an unconnected socket would help, too. To do that you need to use DTLSv1_listen(). I recently wrote a man page for this function, but it hasn't hit the repo yet. Attached FYI. Thanks. DTLSv1_listen is very odd because it has a socket address as an “out” parameter, but no socket address length as an “in/out” argument. It doesn't seem very transport-agnostic, either. It is assumed that the sockaddr structure that you pass in is big enough for whatever addressing scheme the underlying BIO is using. Thus if you're listening on an IPv4 address pass in a pointer to a struct sockaddr_in. If you're listening on an IPv6 address pass in a pointer to a struct sockaddr_in6. Agreed, it's not particularly transport-agnostic. Perhaps just a plain void * would be better. By the time it gets passed to your BIO ctrl function (if you implement your own) it's been cast to a void * anyway! Matt ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] FIPS mode restrictions and DES
Two things to consider with IPSec: key exchange mechanisms as provided by packages like StrongSwan, and the actual encryption/authentication of packets that is typically being done by the kernel stack and I believe is based on the Kernel Crypto API. So I believe to do IPSec you do need both crypto libraries to be FIPS-validated, perhaps as separate crypto modules. Kevin On Tue, Apr 14, 2015 at 8:51 AM, jonetsu jone...@teksavvy.com wrote: Salz, Rich wrote As the old joke goes, if you have to ask, you can't afford it. Well, exploration can be free. I noticed that Strongswan uses a plug-in architecture for crypto that seemingly allows the use of OpenSSL instead of the kernel for crypto operations, for use under FIPS. Does anyone have an idea of the order of magnitude in performance loss this could be for IPSec, to use crypto from OpenSSL instead of the kernel ? Regards. -- View this message in context: http://openssl.6102.n7.nabble.com/openssl-users-FIPS-mode-restrictions-and-DES-tp57497p57541.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 ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] FIPS mode restrictions and DES
Salz, Rich wrote As the old joke goes, if you have to ask, you can't afford it. Well, exploration can be free. I noticed that Strongswan uses a plug-in architecture for crypto that seemingly allows the use of OpenSSL instead of the kernel for crypto operations, for use under FIPS. Does anyone have an idea of the order of magnitude in performance loss this could be for IPSec, to use crypto from OpenSSL instead of the kernel ? Regards. -- View this message in context: http://openssl.6102.n7.nabble.com/openssl-users-FIPS-mode-restrictions-and-DES-tp57497p57541.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
