Re: [PATCH] cfi/fpo directives in md5 assembly code
I agree entirely, but why not fix the other registers while we're at it?
I've attached a version of your diff with the extra registers' unwind info
added--- untested, unfortunately--- it'll also need a
sub ::cfi_restore { ::emit(.cfi_restore,@_); }
in x86gas.pl and the corresponding stub for MASM.
Several of the other assembly files could use the same treatment as well:
md5-x86_64.pl uses %rbp to point to one of its arguments, sha1-586.pl uses
%ebp as a scratch register, etc.
I currently do not have the time to continue working on it.
Since I tested my patch carefully, and since it makes the code better, maybe
we can merge it to trunk, and continue to work on your suggestions later on.
Sound good?
Re: [openssl.org #2549] [Bug report / Linux / openssl 0.9.8k-7ubuntu8.6] openssl s_client does not verify certificate against server's host name
On 27/06/11 11:54, Peter Sylvester via RT wrote: On 06/26/2011 08:05 PM, Peter Sylvester wrote: On 06/26/2011 02:59 PM, Alain Knaff via RT wrote: Hello, openssl s_client -connect hostname.domain.com:443 does not verify that the certificate matches the hostname. (i.e. hostname.domain.com should match either the CN of subject, or in one of the subjectAltNames) Without such verification any web site owner who has a certificate can mount a man-in-the-middle attack against any other web site. verifying a hostname is not part of SSL/TLS layer. OTOH It might have been a good idea 10 years ago to have a function in openssl to permit hostname verification in case of usage for https, one might have avoided some strange certificate content. But extension support was somewhat weak. I think it is still a good idea to implement this. I've tried to use openssl to check certificate installations on our server. Indeed, it has happened often in the past that we had mixups with chained certificates. When this happens, the browser does not flag the problem, if the chain certificate happens to be in its cache due to an earlier visit to the same site (when it was still ok), or to another site which uses the same CA. So, when doing such tests with a browser, I need to be extra careful to manually remove any chained certificates, which is cumbersome. Openssl now looked promising for doing this test, as it doesn't have any such cache. But unfortunately, it doesn't catch mismatches with server names :-( ... there are multiple common names, some clients test the last, some the first occurence in the DN. That's why it is useful to have a reliable test tool. Some clients totally ignore subjectAltNames. etc. Most mainstream clients nowadays do support subjectAltNames. It would be interesting to see possible parameters for a function that would attempt to implement rfc6125. :-) regards Thanks, Alain __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: Build Error on 1.0.1 with FIPS
Thanks Steve. This helps a lot. One more related question: Why are the FIPS test vectors different for different platforms? It seems like Windows and Linux, for example, should both be able to encrypt the same things and produce the same outputs. Thanks again, Tyrel On Tue, Jun 28, 2011 at 10:44 AM, Dr. Stephen Henson st...@openssl.org wrote: On Tue, Jun 28, 2011, Tyrel Haveman wrote: All, I'm having a problem when building OpenSSL 1.0.1 along with fips-2.0. My layout is like this: /home/tyrel/openssl-test/openssl -- contains the 1.0.1 branch from CVS /home/tyrel/openssl-test/fips -- contains the extract fips-2.0 snapshot tarball My build steps are (from the openssl-test dir): cd fips ./config no-asm no-hw --prefix=/home/tyrel/openssl-test/dep make make install cd .. cd openssl export FIPSDIR=/home/tyrel/openssl-test/dep export FIPSLIBDIR=/home/tyrel/openssl-test/dep/lib ./config fips no-asm no-hw --prefix=/home/tyrel/openssl-test/dep make depend make make install The config script indicated that I should run make depend because you've disabled or enabled at least one algorithm. But make depend is the step that is failing. Log is below. It's worth noting that even though make depend fails, I can run make just fine. Is make depend even necessary, then, in this case? You don't need to run make depend. Also the steps you use above should be changed. Set FIPSDIR only and no other environment variables before you even build the test 2.0 module. You can only do: ./config make make install for the FIPS test 2.0 module build. No other options are permitted. In the past no-asm was permitted but this time no one has (so far) sponsored the C only build. For the FIPS capable build you can include additional options but don't set --prefix in the FIPS capable build to the same directory as FIPSDIR. The test 2.0 module and the FIPS capable OpenSSL should go in different places. You can skip make depend. 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 Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: Build Error on 1.0.1 with FIPS
On Wed, Jun 29, 2011, Tyrel Haveman wrote: Thanks Steve. This helps a lot. One more related question: Why are the FIPS test vectors different for different platforms? It seems like Windows and Linux, for example, should both be able to encrypt the same things and produce the same outputs. They are interchangable it's just that those are the testvectors produced by that particular platform during testing. 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 Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: Build Error on 1.0.1 with FIPS
On 06/29/2011 04:46 PM, Dr. Stephen Henson wrote: On Wed, Jun 29, 2011, Tyrel Haveman wrote: Thanks Steve. This helps a lot. One more related question: Why are the FIPS test vectors different for different platforms? It seems like Windows and Linux, for example, should both be able to encrypt the same things and produce the same outputs. They are interchangable it's just that those are the testvectors produced by that particular platform during testing. The formal testing process requires that a unique set of test vectors (request files) be generated for each test platform (operational environment). Once such a set is used for one platform and the response files confirmed as correct it cannot be used again for any formal testing. Presumably that is to keep the vendors (i.e. us) from cheating by hard-coding the correct answers. By now we have encountered quite a few of these test vector sets, but as they are interchangeable there is no point in keeping more than a few representative samples. -Steve M. -- Steve Marquess OpenSSL Software Foundation, Inc. 1829 Mount Ephraim Road Adamstown, MD 21710 USA +1 877-673-6775 marqu...@opensslfoundation.com __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [PATCH] cfi/fpo directives in md5 assembly code
On 28 Jun 2011, at 5:56 PM, Wim Lewis wrote: Several of the other assembly files could use the same treatment as well: md5-x86_64.pl uses %rbp to point to one of its arguments, sha1-586.pl uses %ebp as a scratch register, etc. It occurs to me that a lot of the CFI management could be done automatically in push(), etc., if the script keeps a little bit of state. On 29 Jun 2011, at 12:01 AM, yoni londner wrote: I currently do not have the time to continue working on it. Since I tested my patch carefully, and since it makes the code better, maybe we can merge it to trunk, and continue to work on your suggestions later on. Sound good? I wasn't proposing that the other changes had to be done now --- just noting that the lack of unwind information seems to be a problem that most of the assembly files have. I think the extra registers' unwind info for the md5 asm is worth including now, though, since it's a tiny enhancement. But it's kind of moot since no one with commit access has weighed in. I'll be away for a while, but I'll see if I can test the md5 patches and possibly look at some other asm files when I get back. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
