On 09/02/2016 14:36, Rainer Jung wrote:
> Hi Steve,
>
> thanks a lot for your review and comments. More inline.
>
> Am 09.02.2016 um 13:34 schrieb Dr Stephen Henson:
>> On 09/02/2016 10:20, Rainer Jung wrote:
>>>
>>> 3) ssl_engine_ocsp.c
>>>
sk_value
#endif
no longer work because stacks are now inline functions. If you put that block
round an appropriate #ifdef it should be fine.
I had a quick look at the changes and did notice that some of the direct
structure access (extensions, X509_NAME) is unnecessary in existing versions of
435 showed that leaks disappeared after reverting this
> patch and it does not seem to break anything here.
>
I just checked the sources and this was fixed in OpenSSL 0.9.7m just over 7
years ago...
Steve.
--
Dr Stephen Henson. OpenSSL Software Foundation, Inc.
1829 Mount Ephraim Road
Adamstown, MD 21710
+1 877-673-6775
shen...@opensslfoundation.com
der control of SSLCipherSuite?
>
It looks like OpenSSL isn't receiving that cipher string properly or if it is
being overridden by something else possible elsewhere in the config file. You
can probe individual ciphersuites using s_client like this:
openssl s_client -connect www.hostname.
On 27/03/2014 13:01, Emilia Kasper wrote:
>
>
>
> On Wed, Mar 26, 2014 at 4:56 PM, Dr Stephen Henson
> mailto:shen...@opensslfoundation.com>> wrote:
>
> On 26/03/2014 13:38, Emilia Kasper wrote:
> >
> > On Wed, Mar 26, 2014 at 1:11 PM
On 26/03/2014 13:38, Emilia Kasper wrote:
>
> On Wed, Mar 26, 2014 at 1:11 PM, Dr Stephen Henson
> mailto:shen...@opensslfoundation.com>> wrote:
>
>
> If the server is correctly configured to exclude the root then the chain
> build
> will fail.
or the patch itself. There could be a cleaner way to achieve the same thing.
We're already optionally iterating through all certificates for OCSP staping
using the 1.0.2 APIs so perhaps that can be adapted to perform a chain build
sanity check at the same time.
Steve.
--
D
sions:
For 0.9.8 branches: 0.9.8y affected, only fixed in 0.9.8 snapshots.
For 1.0.0 branches: 1.0.0k affected fixed in 1.0.0l
For 1.0.1 branches: 1.0.1d, 1.0.1e affected fixed in 1.0.0f
Steve.
--
Dr Stephen Henson. OpenSSL Software Foundation, Inc.
1829 Mount Ephraim Road
Adamstown, MD 21710
+1 877-673-6775
shen...@opensslfoundation.com
A quick grep for the SSL_OP_NO_TICKET flag (which disables tickets) in mod_ssl
came up empty so yes that is the only way. That should also work with 2.4.x but
in both cases it requires OpenSSL 1.0.2.
Steve.
--
Dr Stephen Henson. OpenSSL Software Foundation, Inc.
1829 Mount Ephraim Road
Adamstown
no easy workaround for 0.9.8 except upgrading to 1.x, I'd say we
> should implement the workaround suggested by Steve.
>
Applied to trunk as r1576741. I've tried to keep the changes to the absolute
minimum.
I've tested OpenSSL 0.9.8y without this change and can reproduce t
fic versions of OpenSSL might not have included the fix. This is the
actual diff:
http://git.openssl.org/gitweb/?p=openssl.git;a=commitdiff;h=147dbb2fe3bead7a10
Steve.
--
Dr Stephen Henson. OpenSSL Software Foundation, Inc.
1829 Mount Ephraim Road
Adamstown, MD 21710
+1 877-673-6775
shen...@opensslfoundation.com
On 12/03/2014 00:30, Dr Stephen Henson wrote:
>
> The fix was applied on Feb 11 2013. That would mean that official releases
> affected would be 0.9.8y, 1.0.0j and 1.0.1c. Any later official release should
> include the fix but we weren't planning to make any more 0.9.8 off
ks () from
> /usr/local/lib/libssl.so.8
> (gdb) bt full
> #0 0x00010287a19a in ssl_set_cert_masks () from
> /usr/local/lib/libssl.so.8
> No symbol table info available.
> #1 0x00010287a6f6 in ssl_get_server_send_pkey () from
> /usr/local/lib/libssl.so.8
Could be a known issu
On 21/02/2014 13:13, Dr Stephen Henson wrote:
> On 21/02/2014 13:02, Jeff Trawick wrote:
>> Including dev@httpd.apache.org...
>>
>> Is anybody else seeing the same behavior? Looking at the documentation, 2.4.7
>> has gained some performance improvements, but I’m seeing
it's the increased DH parameter size? If it has increased from 1024 bits
to 2048 that would have a significant effect.
OpenSSL 1.0.2 s_client can help check this, if you do:
openssl s_client -connect www.host.com:443
it says (among lots of other stuff):
Server Temp Key: DH, bits
Steve.
--
he current certificate in OpenSSL to the
one the server used.
Steve.
--
Dr Stephen Henson. OpenSSL Software Foundation, Inc.
1829 Mount Ephraim Road
Adamstown, MD 21710
+1 877-673-6775
shen...@opensslfoundation.com
you build and install a shared version of the FIPS capable OpenSSL this
shouldn't happen.
Steve.
--
Dr Stephen Henson. OpenSSL Software Foundation, Inc.
1829 Mount Ephraim Road
Adamstown, MD 21710
+1 877-673-6775
shen...@opensslfoundation.com
asonable option when I first started this venture.
>
Ah... there was a recent fix for this which hasn't yet appeared in an official
OpenSSL release. This means that configuring OpenSSL with "zlib" wont create
correct *.pc files. The "zlib-dynamic" option (which lin
On 20/02/2014 00:24, Tom Browder wrote:
> On Wed, Feb 19, 2014 at 7:09 PM, Dr Stephen Henson
> wrote:
> ..
>>> checking for OpenSSL version >= 0.9.7... OK
>
>> Well something is wrong there with it indicating OpenSSL version 0.9.7. If
>> you
>> inte
On 20/02/2014 00:24, Tom Browder wrote:
> On Wed, Feb 19, 2014 at 7:09 PM, Dr Stephen Henson
> wrote:
>> On 19/02/2014 23:54, Tom Browder wrote:
>>> On Wed, Feb 19, 2014 at 11:21 AM, Tom Browder wrote:
>>>> On Wed, Feb 19, 2014 at 10:53 AM, Dr Stephen Henson
&g
On 19/02/2014 23:54, Tom Browder wrote:
> On Wed, Feb 19, 2014 at 11:21 AM, Tom Browder wrote:
>> On Wed, Feb 19, 2014 at 10:53 AM, Dr Stephen Henson
>> wrote:
>>> On 19/02/2014 15:08, Tom Browder wrote:
>>>> I configured httpd-2.4.7 successfully to use mod_ss
On 19/02/2014 20:17, Jeff Trawick wrote:
> On Wed, Feb 19, 2014 at 2:23 PM, Dr Stephen Henson
> mailto:shen...@opensslfoundation.com>> wrote:
>
> That works for two cases above. If however the on the fly chain building
> is
> performed it will fail.
>
>
&
On 19/02/2014 20:17, Jeff Trawick wrote:
> On Wed, Feb 19, 2014 at 2:23 PM, Dr Stephen Henson
> mailto:shen...@opensslfoundation.com>> wrote:
>
> On 19/02/2014 18:37, Jeff Trawick wrote:
> >
> >
> > I think this is the trick...
> >
al.
You can use SSL_CTX_get_extra_chain_certs which retrieves the chain for the
current certificate or (if it is empty) the per-ctx chain.
That works for two cases above. If however the on the fly chain building is
performed it will fail.
Steve.
--
Dr Stephen Henson. OpenSSL Software Foundation, Inc.
1829 Mount Ephraim Road
Adamstown, MD 21710
+1 877-673-6775
shen...@opensslfoundation.com
522: undefined reference to
> `FIPS_rand_seed'
>
That could be user error. The path /usr/local/ssl/fips-2.0 is the default
install location of the FIPS module which isn't a complete version of OpenSSL.
It should point to the location the FIPS capable OpenSSL is
On 18/02/2014 20:06, Jeff Trawick wrote:
> On Mon, Feb 3, 2014 at 6:21 AM, Dr Stephen Henson
> <mailto:shen...@opensslfoundation.com>> wrote:
>
> On 02/02/2014 13:45, Kaspar Brand wrote:
> > On 01.02.2014 14:37, Dr Stephen Henson wrote:
> >> I&#
.bar:443:0 for stapling
>
>
> + if (parg == NULL && larg == 0)
> + *(STACK_OF(X509) **)parg = ctx->cert->key->chain;
>
> In theory, I cannot find an error in your change though.
> Kaspar, do you have an idea?
just pull the latest 1.0.2 branch from git.
Steve.
--
Dr Stephen Henson. OpenSSL Software Foundation, Inc.
1829 Mount Ephraim Road
Adamstown, MD 21710
+1 877-673-6775
shen...@opensslfoundation.com
cates using
SSL_CTX_get_extra_chain_certs. With the 1.0.2 changes to
SSL_CTX_use_certificate_chain_file that would fail in 1.0.2 without that change.
On balance I think that change should go in OpenSSL. I'll hear soon enough if it
breaks anything...
Steve.
--
Dr Stephen Henson. OpenSSL Sof
On 02/02/2014 13:45, Kaspar Brand wrote:
> On 01.02.2014 14:37, Dr Stephen Henson wrote:
>> I'm wondering how that could be avoided. Would a way to enumerate all
>> certificates in an SSL_CTX structure in OpenSSL help? Something like
>> SSL_CTX_ge
ed. Would a way to enumerate all
certificates in an SSL_CTX structure in OpenSSL help? Something like
SSL_CTX_get0_first_certificate() and SSL_CTX_get0_next_certificate(). That would
also set the current certificate at the same time in case applications wanted to
inspect the private key or chai
c52cc3c0d.1030...@velox.ch%3E
>
>
IMHO, yes.
Steve.
--
Dr Stephen Henson. OpenSSL Software Foundation, Inc.
1829 Mount Ephraim Road
Adamstown, MD 21710
+1 877-673-6775
shen...@opensslfoundation.com
ould probably
> be a somewhat more intrusive change, compared to what has been done for
> the server-side part so far.
>
I wasn't sure of the details of the current implementation either. Would it be
appropriate to have SSL_CONF usable with SSLProxy* too?
Steve.
--
Dr Stephen Henso
On 05/01/2014 09:00, Kaspar Brand wrote:
> On 03.01.2014 23:51, Dr Stephen Henson wrote:
>> On 28/12/2013 13:34, Kaspar Brand wrote:
>>> FYI: in r1553824 (which I just committed to trunk), I'm now manually
>>> shuffling things around to support per-cert chains - but
; interface in mod_ssl but not yet workable?) Or maybe I'm not looking at the
> right place in OpenSSL.
>
I just added it to the OpenSSL master branch. Let me know if you have any
problems. I'll backport it to 1.0.2 before release.
Steve.
--
Dr Stephen Henson. OpenSSL Software Foun
On 28/12/2013 13:34, Kaspar Brand wrote:
> On 18.11.2013 18:42, Kaspar Brand wrote:
>> On 18.11.2013 15:38, Dr Stephen Henson wrote:
>>> For OpenSSL 1.0.2 this limitation is removed and you can have different
>>> chains
>>> for each certificate type (and for
es which can be set at the SSL_CTX or SSL level. See:
http://www.openssl.org/docs/ssl/SSL_CTX_set1_verify_cert_store.html
Steve.
--
Dr Stephen Henson. OpenSSL Software Foundation, Inc.
1829 Mount Ephraim Road
Adamstown, MD 21710
+1 877-673-6775
shen...@opensslfoundation.com
pts to use the dynamic
ENGINE to load an ENGINE from an appropriate directory with an appropriate name.
The precise location depends on how OpenSSL is configured but it might for
example try to load "/usr/local/ssl/engines/libpkcs11.so". If that fails you get
an error.
It's only if you wan
Well at present there is no ENGINE interface for SSL_CONF. As pointed out it
isn't a good fit for general ENGINE configuration but it could be updated in
future to support ENGINE based private keys.
Steve.
--
Dr Stephen Henson. OpenSSL Software Foundation, Inc.
1829 Mount Ephraim Road
Adamstown, MD 21710
+1 877-673-6775
shen...@opensslfoundation.com
ve in OpenSSL though some third party ENGINEs do
include partial support.
Completely transparent support is tricky (and in some cases impossible) due
several factors including the way PKCS#11 handles fork().
Steve.
--
Dr Stephen Henson. OpenSSL Software Foundation, Inc.
1829 Mount Ephraim Road
Adams
On 17/11/2013 15:25, Dr Stephen Henson wrote:
>
> Evil hack workaround: create a temporary SSL structure from the SSL_CTX of
> interest after you call SSL_CTX_get_certificate, call SSL_get_certificate on
> it
> and then free up the temp SSL structure. That *should* work on all
versions
of OpenSSL of interest. That's not very efficient and makes me cringe a bit but
you'd only go through it once on start up.
Steve.
--
Dr Stephen Henson. OpenSSL Software Foundation, Inc.
1829 Mount Ephraim Road
Adamstown, MD 21710
+1 877-673-6775
shen...@opensslfoundation.com
documented that they might not work as expected?
The SSL_CONF code (which SSLOpenSSLConfCmd uses) should have support for
encrypted private keys as other applications might want to use it. The SSL_CONF
code wasn't designed exclusively for mod_ssl use: though I have to admit I was
partly thinking about h
le based keys. If in future you want to
support a key in an HSM it may not be even possible to serialise it. The
"passphrase" may also be outside software control (for example entered into the
device via a pinpad).
Steve.
--
Dr Stephen Henson. OpenSSL Software Foundation, Inc.
1829 Mount
On 23/10/2013 15:30, Kaspar Brand wrote:
> On 22.10.2013 22:04, Dr Stephen Henson wrote:
>> Only bit I'm not completely sure about is the use of the SSL_CONF_CTX
>> structure
>> in modssl_ctx_t. It's done that way to avoid having to keep creating and
>>
On 22/10/2013 20:14, Trevor Perrin wrote:
> On Mon, Oct 21, 2013 at 5:45 AM, Dr Stephen Henson
> wrote:
>> On 21/10/2013 05:09, Trevor Perrin wrote:
>>>
>>
>> BTW I've just added some experimental code to the OpenSSL master branch. It
>> adds
>
before by
the existing Apache certificate directives) and set it as the current
certificate, which any subsequent options will use.
Steve.
--
Dr Stephen Henson. OpenSSL Software Foundation, Inc.
1829 Mount Ephraim Road
Adamstown, MD 21710
+1 877-673-6775
shen...@opensslfoundation.com
On 11/10/2013 05:14, Kaspar Brand wrote:
> On 09.10.2013 15:52, Dr Stephen Henson wrote:
>> It's tempting to just add a directive but after some thought I think
>> expanding
>> Apache SSL_CONF handling is the way to go. This would add some future
>> proofing
&
t;. How about instead having a single one indexed as "vhost"? This
could contain all keys and certificates in a single buffer. Keys would be stored
in PKCS#8 format to avoid algorithm dependencies.
The auto increment feature of the i2d/d2i functions is especially designed to
support this
e SSL_AIDX_ values?
After that you look for an appropriate ServerInfo value when SSL_use_certificate
or SSL_use_PrivateKey is called (you'll be able to use the associated
SSL_AIDX_ value) and set the ServerInfo.
There *should* be an easier way to do it than this but I can't immediately
On 02/10/2013 08:35, Kaspar Brand wrote:
> On 01.10.2013 12:15, Dr Stephen Henson wrote:
>> That's just OpenSSL internals though. To handle ServerInfo properly in
>> mod_ssl
>> IMHO you would need a new directive as there's no support for per-certificate
>>
On 09/10/2013 02:22, Trevor Perrin wrote:
> Hi Kaspar, Stephen,
>
> So I think where things stand is that the OpenSSL 1.0.2 branch is
> capable of handling ServerInfo on a per-algorithm basis, but it's not
> clear how to expose this through Apache.
>
> (My previ
On 01/10/2013 11:15, Dr Stephen Henson wrote:
>
> To handle ServerInfo properly in mod_ssl
> IMHO you would need a new directive as there's no support for per-certificate
> SSL_CONF commands: it wasn't intended to be used like that in its current
> form.
>
Though t
On 01/10/2013 05:53, Trevor Perrin wrote:
> On Sun, Sep 29, 2013 at 1:06 AM, Kaspar Brand wrote:
>> On 28.09.2013 18:34, Dr Stephen Henson wrote:
>>> How about something like:
>>>
>>> int SSL_CONF_cmd_type(SSL_CONF_CTX *cctx, const char *cmd);
On 28/09/2013 14:56, Dr Stephen Henson wrote:
> On 28/09/2013 14:42, Kaspar Brand wrote:
>>
>> If the ability to specify relative path names with SSLOpenSSLConfCmd is
>> considered an absolutely essential feature, then OpenSSL could perhaps
>> "standardize"
take a file name argument with "...File". We could then handle
> such a case in mod_ssl as illustrated by the attached patch.
>
An alternative would be to specify a callback to OpenSSL which can be used to
"transform" a filename which is called whenever any option name requ
nfoFile", "serverinfo"},
It gets supported in command line utilities to (like s_server, making it
unnecessesary to code it separately). Also if it is only used for servers you
need something like:
if (!(cctx->flags & SSL_CONF_FLAG_SERVER))
return
er control of EC parameters: e.g. if it is
desired to use non-default curve preferences. While this can be done explicitly
at the Apache level I'd suggest instead that the SSL_CONF support code is
backported instead: which supports a lot more. If there's anything I can do to
help with that
when ticket keys are created. So if you make several connections to the
same server you'll get those same 0x10 bytes at the start.
If you then perform a graceful restart and connect again those 0x10 bytes should
be different.
Steve.
--
Dr Stephen Henson. OpenSSL Software Foundation, Inc.
1829 Mount Ephraim Road
Adamstown, MD 21710
+1 877-673-6775
shen...@opensslfoundation.com
On 01/09/2013 12:36, Stefan Fritsch wrote:
> Am Mittwoch, 21. August 2013, 12:37:53 schrieb Dr Stephen Henson:
>>> It would be desirable (perhaps) if we could rotate keys faster
>>> than once the server lifetime, but this is shared state across
>>> the server so
server so that
> is definitely non-trivial.
>
Yes you'd need a shared cache if the key couldn't be found locally and renew it
periodically. A bit like how OCSP stapling works IIRC.
> Any opinions here?
>
The default key size is also 128 bits for the encryption and HMAC
(there is provisional code for
this in 2.5-dev) can be configured using the SSLOpenSSLConfCmd directive. ECDH
curves (and many other things) can be set this way.
Steve.
--
Dr Stephen Henson. OpenSSL Software Foundation, Inc.
1829 Mount Ephraim Road
Adamstown, MD 21710
+1 877-673-6775
shen...@opensslfoundation.com
ICT you would
> have to call "openssl version -f" and look for any flags set at compile
> time.)
>
> I.e., unless mod_ssl is explicitly compiled with -DOPENSSL_NO_SSL2 (set
> through CPPFLAGS/CFLAGS), an #ifdef OPENSSL_NO_SSL2 has no effect, and
> the blocks enclosed wi
this quirk has been addressed in the current development version of
OpenSSL. It's now possible to set certificate chains on a per-type and per-SSL
context basis, instead of one per parent SSL_CTX. The functionality is likely to
be back ported to OpenSSL 1.0.2.
Steve.
--
Dr Stephen Henson. OpenSSL Software Foundation, Inc.
1829 Mount Ephraim Road
Adamstown, MD 21710
+1 877-673-6775
shen...@opensslfoundation.com
keys for server
configuration and so the data should come from trusted sources.
Steve.
--
Dr Stephen Henson. OpenSSL Software Foundation, Inc.
1829 Mount Ephraim Road
Adamstown, MD 21710
+1 877-673-6775
shen...@opensslfoundation.com
puppies or Lord
> Palmerston? Of course no one gets it...
>
>
I was either that, bicycles or asking if someone had passed their driving test.
Steve.
--
Dr Stephen Henson. OpenSSL Software Foundation, Inc.
1829 Mount Ephraim Road
Adamstown, MD 21710
+1 877-673-6775
shen...@opensslfoundation.com
human side of the authors.
If we want to make the whole thing bland and faceless then so be it. I think it
will be lessened as a result.
If that's "sentimental" then I suppose I am.
I'd like to hear other peoples opinions on this.
Steve.
--
Dr Stephen Henson. OpenSSL Softw
ng the curve to
use with minimal computational overhead. OpenSSL could just do the right thing
automatically here and send back a curve the peer is willing to use and server
applications would then automatically support EC.
Steve.
--
Dr Stephen Henson. OpenSSL Software Foundation, Inc.
1829 Mount
re or just call ssl_callback_tmpECDH before
starting any threads. Alternatively if you're just setting one curve then you
might as well call SSL_CTX_set_tmp_ecdh and avoid the callback altogether.
[BTW the whole ECDH parameter passing technique is a bit broken in OpenSSL and
needs revising]
Steve
On 05/02/2012 11:08, Kaspar Brand wrote:
> On 04.02.2012 15:27, Dr Stephen Henson wrote:
>> IMHO to avoid these problems it would be better if mod_ssl could send an
>> arbitrary number of certificates and keys to OpenSSL and leave it to OpenSSL
>> to
>> process th
er control over some operations (for example to detect configuration
errors) is required OpenSSL could be extended to support that.
Thoughts?
Steve.
--
Dr Stephen Henson. OpenSSL Software Foundation, Inc.
1829 Mount Ephraim Road
Adamstown, MD 21710
+1 877-673-6775
shen...@opensslfoundation.com
On 04/02/2012 07:32, Kaspar Brand wrote:
> On 02.02.2012 15:13, Dr Stephen Henson wrote:
>>
>> int SSL_CTX_config(SSL_CTX *ctx, const char *config_name);
>>
>> Where "config_name" is a named configuration option in the OpenSSL
>> configuration
>&
there is a possibility that the some chain verification leaves a reference to
an RSA key which prevents the ENGINE from closing down completely.
In engines/e_chil.c try commenting out the line containing
ERR_load_HWCRHK_strings().
Only side effect of doing that is you will only get numerical erro
onfiguration file to use wouldn't be
hard coded. There would be a separate API which would allow an application to
decide which configuration file to use. It could be either a system wide one or
a local one dealing with mod_ssl only.
Steve.
--
Dr Stephen Henson. OpenSSL Software Foundation, Inc.
1829 Mount Ephraim Road
Adamstown, MD 21710
+1 877-673-6775
shen...@opensslfoundation.com
; is a named configuration option in the OpenSSL configuration
file. This has the substantial advantage that there would
then be one configuration file format used by all OpenSSL applications.
The disadvantage is that it would look nothing like the existing Apache
configuration format.
Thoughts
ent openssl
> (0.9.8r). I didn't explicitly enable optimization of either build but
> did explicitly add "-g" which seemed to create a build of httpd with
> debug symbols but a regular old build of openssl. I have some other
> platforms available (RHEL being one of the
On 23/12/2011 07:52, Kaspar Brand wrote:
> On 22.12.2011 17:53, Dr Stephen Henson wrote:
>> I've added a few new controls and one new function which should resolve this,
>> see last few commits.
>>
>> I deleted a couple of functions duplicating functionality to
On 22/12/2011 10:59, Kaspar Brand wrote:
> On 05.08.2011 07:41, Kaspar Brand wrote:
>> On 03.08.2011 19:29, Dr Stephen Henson wrote:
>>> In OpenSSL 1.0.1 (unreleased) and later there is a feature to make all SSL
>>> related structures opaque and only allow
Steve can confirm (?). Adding a short comment as to why
> the first cert is dropped would be useful IMO, too.
>
Yes you need store the returned value and free it with X509_free().
Note also that because you ignore return values of X509_verify_cert() you might
have a situation where the c
st added to the chain. You can
replace that all with:
chain = X509_STORE_CTX_get1_chain(sctx);
which creates a STACK_OF(X509) and ups the reference count of the added
certificates so they stick around after you free the context.
Steve.
--
Dr Stephen Henson. OpenSSL Software Foundation, Inc.
1829
problems because sometimes a certificate "chain"
which doesn't quite fit the PKIX definition is used. An example would be a proxy
certificate chain (for some value of "proxy", not necessarily standard)
where some certificates in the chain are not CA certificates in the normal
definition (basic constraints CA=TRUE). That kind of "chain" cannot directly be
built up using X509_verify_cert().
Steve.
--
Dr Stephen Henson. OpenSSL Software Foundation, Inc.
1829 Mount Ephraim Road
Adamstown, MD 21710
+1 877-673-6775
shen...@opensslfoundation.com
subject/issuer) but not self signed. Admittedly such cases are
comparatively rare outside compliance tests...
So instead of manually building the chain why not handle it automatically or at
least have the option to do so? The X509_verify_cert function in OpenSSL can do
this. This has the advantage t
to fail without some modification. There may well be some
functionality missing in OpenSSL too.
Ironically to support this you'd need to avoid some of the changes in this
patch. For example:
-l = strlen(SSL_CIPHER_get_name(c));
-memcpy(cp, SSL_CIPHER_get_name(c), l);
+l =
nabling FIPS mode doesn't guarantee compliance:
you also need to adhere to the requirements of the security policy.
Steve.
--
Dr Stephen N. Henson. Senior Technical/Cryptography Advisor,
Open Source Software Institute: www.oss-institute.org
OpenSSL Core team: www.openssl.org
validation for valid self-signed certs, I
> brought this up a while back:
>
> http://www.mail-archive.com/dev@httpd.apache.org/msg38849.html
>
> and Stephen said it probably be configurable. Has common practice
> evolved here such that hard-coding the less strict behaviour i
On 02/01/2011 18:42, Stefan Fritsch wrote:
> On Sunday 02 January 2011, Dr Stephen Henson wrote:
>
>> There is a bug in OpenSSL currently for those options: it doesn't
>> escape the escape character itself (which it should treat as a
>> special case and always escap
er escaping is in use). That means some representations are
ambiguous with those options.
When that is fixed even 7 bit without control characters will have at least one
difference: the backslash will always appear escaped as "\\".
Steve.
--
Dr Stephen N. Henson. Senior Technical/Cryptography Advisor,
Open Source Software Institute: www.oss-institute.org
OpenSSL Core team: www.openssl.org
t to be uncovered.
My personal opinion would be to, at least initially, require an explicit
directive to enable it and leave the option in future to have it enabled by
default.
Anyone else have any thoughts on the matter?
Steve.
--
Dr Stephen N. Henson. Senior Technical/Cryptography
On 29/11/2010 19:34, Dr Stephen Henson wrote:
>
> You can get a UTF8String from most string types using ASN1_STRING_to_UTF8().
> This should be adequate for most purposes: it doesn't handle the more bizarre
> TeletexString shift conversions but those are rarely encountered i
n practice: if an OCSP responder doesn't respond in a few seconds it
isn't likely to respond at all.
Steve.
--
Dr Stephen N. Henson. Senior Technical/Cryptography Advisor,
Open Source Software Institute: www.oss-institute.org
OpenSSL Core team: www.openssl.org
On 30/11/2010 00:03, Dr Stephen Henson wrote:
> On 29/11/2010 21:46, Guenter Knauf wrote:
>> Hi Steve,
>> ssl_util_stapling.c issues warnings / breaks when compiled with OSSL 1.0.0;
>> MSVC
>> warns:
>> \modules\ssl\ssl_util_stapling.c(140) : warning C4133: '
that we had some similar already in the past, and you suggested a
> change
> which was compatible with both 0.9.8 and 1.0.0 branches, but I cant recall ...
> Or do we need to cleanly solve this with some version-depent defines?
>
See of the patch for bug #50121 resolves this for you.
Steve.
--
Dr Stephen N. Henson. Senior Technical/Cryptography Advisor,
Open Source Software Institute: www.oss-institute.org
OpenSSL Core team: www.openssl.org
es be just plain wrong (BMPStrings is one of many examples).
We have to retain it in OpenSSL for backwards compatibility though. I'd throw it
out tomorrow if I could get away with it.
You can get a UTF8String from most string types using ASN1_STRING_to_UTF8().
This should be adequate for mo
mctx->auth.ca_cert_file,
>>mctx->auth.ca_cert_path);
>> -if (!ca_list) {
>> +if (sk_X509_NAME_num(ca_list) == 0) {
>
> Can we be sure that ca_list != NULL or that sk_X509
unlocks.
The update process could take a maybe a second or so. If the lock wasn't there
many instances on a heavily loaded server could query the responder almost
simultaneously.
Steve.
--
Dr Stephen N. Henson. Senior Technical/Cryptography Advisor,
Open Source Software Institute: www.oss-institute.org
OpenSSL Core team: www.openssl.org
openssl 0.9.7a on Redhat 4.
>
It will do: that syntax needs the mini-ASN1 compiler which first appeared in
OpenSSL 0.9.8.
Including the raw encoding with the DER option should work on all versions, you
can generate that with asn1parse in OpenSSL 0.9.8. FYI it is:
0c 06 4c 65 6d 6f 6e 73
Steve.
--
Dr Stephen N. Henson. Senior Technical/Cryptography Advisor,
Open Source Software Institute: www.oss-institute.org
OpenSSL Core team: www.openssl.org
t proposed to 2.2.x, see the SSLFIPS directive.
Steve.
--
Dr Stephen N. Henson. Senior Technical/Cryptography Advisor,
Open Source Software Institute: www.oss-institute.org
OpenSSL Core team: www.openssl.org
ds on the version of OpenSSL in use. The ASN1 decoding
functions were constified in 1.0.0 so you get a warning in 1.0.0 if you make
that change or in 0.9.8 with the original...
Steve.
--
Dr Stephen N. Henson. Senior Technical/Cryptography Advisor,
Open Source Software Institute: www.oss-institute.org
OpenSSL Core team: www.openssl.org
ith 0.9.8 if possible).
If you'd said < 0.9.8m (because 0.9.8m and later support reneg extension) I'd be
very much in favour.
I haven't checked but are there many remaining toolkit issues with supporting
0.9.8m and later?
The CRL revocation checking in 0.9.8 is more primitiv
Joe Orton wrote:
> On Wed, Mar 03, 2010 at 06:31:36PM +, Dr Stephen Henson wrote:
>
>> Note that you don't need to abort if secure renegotiation is supported
>> by the client.
>
> Is there any technical need to support client-initiated reneg? It's a
>
1 - 100 of 168 matches
Mail list logo
