[openssl-users] OpenSSL public repository, bug tracker ?
Sorry if this is answered elsewhere ... Is the version control repository as well as the bug tracker of public read access ? Is it possible to find a specific commit in the OpenSSL repository that would hopefully fix a single discovered/reported bug ? We have hit the 'FIPS_CIPHERINIT:disabled for fips' in the 1.0.1e version running in FIPS mode and would like to apply the cde fix that hopefully fixes only that problem. Is it possible ? Thanks. ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] OpenSSL public repository, bug tracker ?
> Is the version control repository as well as the bug tracker of public read > access ? https://www.openssl.org/source/ ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] OCSP_sendreq_bio()
On 28.10.2015 17:27, Steve Marquess wrote: There are environments where https must be used for OCSP, due to policy fiat and/or firewall restrictions. -Steve M. OCSP works through proxies; there is no reason for having such strange setups ... Walter smime.p7s Description: S/MIME Cryptographic Signature ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] Where to find the OCSP response signer cert if the OCSP response does not contain one?
On 28/10/2015 10:24, M K Saravanan wrote: Hi, Upon checking the wireshark capture, I found the OCSP response does not send signer cert, but only the responderID (byKey). In such scenario, where do I find the OCSP response signer cert? Clarifying my own question. https://tools.ietf.org/html/rfc6960#section-4.2.2.3 says: --- The purpose of the ResponderID information is to allow clients to find the certificate used to sign a signed OCSP response. Therefore, the information MUST correspond to the certificate that was used to sign the response. The responder MAY include certificates in the certs field of BasicOCSPResponse that help the OCSP client verify the responder's signature. - I understand that it is not mandatory to send the OCSP response signer certificate in the OCSP response. So in such cases, where to find the OCSP response signer certificate? That is my question. Obvious first check is to see if it is the CA certificate that issued thecertificate you are checking. Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. http://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
Re: [openssl-users] OCSP_sendreq_bio()
On 28.10.2015 16:44, Jakob Bohm wrote: On 27/10/2015 21:21, Walter H. wrote: On 26.10.2015 21:42, rosect...@yahoo.com wrote: Hi, I need some help on this call. I am building an OCSP client following guide in openssl and compile the code in Cygwin environment. My openssl version is 1.0.1h. With HTTP based OCSP, the code works fine. But, with HTTPs, the code gets stuck at the call to OCSP_sendreq_bio(). Further debugging shows that OCSP_sendreq_nbio() does not return. Did I need to something extra to deal with HTTPs based connection? OCSP must not be https ... the same with CRL download ... Really, I thought that was only a recent cop out rule to cater to clients with inferior SSL libraries that can't handle the recursion. both OCSP and CRLs are signed, and this is enough for validation, there is no need of SSL; and an infinite recursion would be implied because of the need of validating these SSL-certificates the same way as the origin SSL-certificate ... but be aware the CRLs can be in an LDAP - done by bad CAs; OCSP must be HTTP Walter smime.p7s Description: S/MIME Cryptographic Signature ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] OCSP_sendreq_bio()
On 10/28/2015 11:44 AM, Jakob Bohm wrote: > On 27/10/2015 21:21, Walter H. wrote: >> ... >>> >> OCSP must not be https ... >> the same with CRL download ... > Really, I thought that was only a recent cop out rule to > cater to clients with inferior SSL libraries that can't > handle the recursion. > > Of cause one should not initiate an HTTPS connection to > a server to (directly or indirectly) validate the servers > certificate for another such connection, but I know no > inherent reason not to use HTTPS for CRL and OCSP access > as long as infinite recursion is avoided, preferably > through the choice of server certificates. There are environments where https must be used for OCSP, due to policy fiat and/or firewall restrictions. -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] OCSP_sendreq_bio()
On 27/10/2015 21:21, Walter H. wrote: On 26.10.2015 21:42, rosect...@yahoo.com wrote: Hi, I need some help on this call. I am building an OCSP client following guide in openssl and compile the code in Cygwin environment. My openssl version is 1.0.1h. With HTTP based OCSP, the code works fine. But, with HTTPs, the code gets stuck at the call to OCSP_sendreq_bio(). Further debugging shows that OCSP_sendreq_nbio() does not return. Did I need to something extra to deal with HTTPs based connection? OCSP must not be https ... the same with CRL download ... Really, I thought that was only a recent cop out rule to cater to clients with inferior SSL libraries that can't handle the recursion. Of cause one should not initiate an HTTPS connection to a server to (directly or indirectly) validate the servers certificate for another such connection, but I know no inherent reason not to use HTTPS for CRL and OCSP access as long as infinite recursion is avoided, preferably through the choice of server certificates. Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. http://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
Re: [openssl-users] OCSP_sendreq_bio()
On 28/10/2015 17:36, Walter H. wrote: On 28.10.2015 16:44, Jakob Bohm wrote: On 27/10/2015 21:21, Walter H. wrote: On 26.10.2015 21:42, rosect...@yahoo.com wrote: Hi, I need some help on this call. I am building an OCSP client following guide in openssl and compile the code in Cygwin environment. My openssl version is 1.0.1h. With HTTP based OCSP, the code works fine. But, with HTTPs, the code gets stuck at the call to OCSP_sendreq_bio(). Further debugging shows that OCSP_sendreq_nbio() does not return. Did I need to something extra to deal with HTTPs based connection? OCSP must not be https ... the same with CRL download ... Really, I thought that was only a recent cop out rule to cater to clients with inferior SSL libraries that can't handle the recursion. both OCSP and CRLs are signed, and this is enough for validation, there is no need of SSL; How about privacy. Especially OCSP queries are very revealing, as they indicate the party sending the query is using that particular 3rd party certificate at that very moment. If the generals computer requests OCSP validation for weather.com, followed by OCSP validation for a service that reports sunrise/sunset, followed by OCSP validation for the e-mail certificates of his top lieutenants, this is as revealing as if he had sent the message "attack at dawn" in the clear. and an infinite recursion would be implied because of the need of validating these SSL-certificates the same way as the origin SSL-certificate ... Only if the SSL certificate for the OCSP or CRL server references itself as a way to check for revocation of *that* certificate (larger multi-step loops could also be built). However with careful choice/generation of certificates for the OCSP/CRL server, this can be easily avoided. but be aware the CRLs can be in an LDAP - done by bad CAs; OCSP must be HTTP I have mostly seen that for site-local CAs that already integrate all their other work with the same LDAP servers. I guess it could also be done by genuine X.500 directory systems as originally envisioned by the ITU (i.e. publishing the actual public phone book via DAP or LDAP, with distinguished names representing their originally intended phone book fields and certificates issued to phone line subscribes according to the usual telephone network hierarchy, CN=US,ST=CA,C=Klondyke,... Serial=1-555-555-), Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. http://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
Re: [openssl-users] Freeing of const char * fields in ASN1_OBJECT
> From: openssl-users [mailto:openssl-users-boun...@openssl.org] On Behalf
> Of Reinier Torenbeek
> Sent: Wednesday, October 28, 2015 16:55
>
> In asn1/asn1.h, the fields sn and ln in ASN1_OBJECT are defined as const
> char *:
>
> 211 typedef struct asn1_object_st
> 212 {
> 213 const char *sn,*ln;
> 214 int nid;
> 215 int length;
> 216 const unsigned char *data; /* data remains const after
> init */
> 217 int flags; /* Should we free this one */
> 218 } ASN1_OBJECT;
>
> but in asn1/a_object.c, the get casted to void * and freed:
>...
>
> Given that a lot of the code is supposed to be self-describing (due to
> lack of documentation), it is somewhat disturbing that I can not rely on
> the const qualifiers to be honored. Any thoughts on this?
It's a well-known problem with the semantics of const in C.
The parameter to free() cannot have the const qualifier, because the semantics
of free say that the object referred to by the pointer reaches the end of its
lifetime during the call to free(), and attempting to use it after that results
in Undefined Behavior.
However, it is perfectly reasonable to want to allocate storage, initialize
(and even alter) its contents, but have that object treated only as an rvalue
elsewhere. This is a very typical use case for a library or other code that
presents an ADT (abstract data type) to a caller.
The mechanism for informing a caller that an object should not be modified is
the const qualifier.
There are only two ways around this problem. One is for the ADT implementation
to keep both a const and a non-const pointer to the same area, publish the
const one, and use the non-const one for freeing. That's a rather absurd
duplication of effort (and a small amount of storage) just to account for C's
simplistic const/free semantics.
The other way, which is the one everyone uses, is to cast away the constness of
the pointer when passing it to free.
Note that the problem arises in other contexts. That's why C++ has a category
of casts just for this purpose (casting away constness). Another case you often
see is a function in an external library that never modifies the object pointed
to by a parameter, but failed to declare it as const (generally because it was
written by someone who doesn't understand C, which is to say ~97% of all C
programmers).
As a rule of thumb, when a function parameter itself is a pointer to a
const-qualified object type (this doesn't apply to const pointers to non-const
objects), you should be able to assume that the function does not change the
object. When a function parameter is a pointer to a non-const-qualified
aggregate type (struct or union) that happens to include const-qualified
members, do NOT assume that there are no cases in which those objects are
modified. You really have to check the implementation of that function.
C function contracts are weak.
Now, a *good* public C library will implement proper ADTs. It will define them
as pointers to incomplete structures, so you can't go poking around inside
them; it will give you construction and cleanup functions; and it will give you
accessor functions. Some people will complain that at that point you're no
longer writing C - you're reinventing C++ - to which I'd reply that they don't
really understand C or C++.
--
Michael Wojcik
Technology Specialist, Micro Focus
___
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
[openssl-users] Const qualifier for EVP_PKEY parameters in pub_encode method
Hi,
While implementing an engine, I run into the following prototype that I
need to implement:
struct evp_pkey_asn1_method_st
{
int (*pub_encode)(X509_PUBKEY *pub, *const* EVP_PKEY *pk);
} /* EVP_PKEY_ASN1_METHOD */;
Inside this function, I want to assign pk to pub->pkey (and do the
necessary up and down reffing of the EVP_PKEYs involved). But that is
not allowed, because of the const qualifier on pk.
For now, I have just worked around the compiler complaints by casting to
a non-const, but I wonder whether this will bite me at some point?
Thanks,
Reinier
___
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
[openssl-users] Freeing of const char * fields in ASN1_OBJECT
Hi,
The following looks wrong and actually resulted in a crash for me before
I decided to do things differently:
In asn1/asn1.h, the fields sn and ln in ASN1_OBJECT are defined as const
char *:
211 typedef struct asn1_object_st
212 {
213 const char *sn,*ln;
214 int nid;
215 int length;
216 const unsigned char *data; /* data remains const after
init */
217 int flags; /* Should we free this one */
218 } ASN1_OBJECT;
but in asn1/a_object.c, the get casted to void * and freed:
378 void ASN1_OBJECT_free(ASN1_OBJECT *a)
379 {
380 if (a == NULL) return;
381 if (a->flags & ASN1_OBJECT_FLAG_DYNAMIC_STRINGS)
382 {
383 #ifndef CONST_STRICT /* disable purely for compile-time strict const
checking. Doing this on a "real" compile will cause memory leaks */
384 if (a->sn != NULL) OPENSSL_free((void *)a->sn);
385 if (a->ln != NULL) OPENSSL_free((void *)a->ln);
386 #endif
Given that a lot of the code is supposed to be self-describing (due to
lack of documentation), it is somewhat disturbing that I can not rely on
the const qualifiers to be honored. Any thoughts on this?
Thanks,
Reinier
___
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] Where to find the OCSP response signer cert if the OCSP response does not contain one?
Hi, > Upon checking the wireshark capture, I found the OCSP response does not send > signer cert, but only the responderID (byKey). > > In such scenario, where do I find the OCSP response signer cert? Clarifying my own question. https://tools.ietf.org/html/rfc6960#section-4.2.2.3 says: --- The purpose of the ResponderID information is to allow clients to find the certificate used to sign a signed OCSP response. Therefore, the information MUST correspond to the certificate that was used to sign the response. The responder MAY include certificates in the certs field of BasicOCSPResponse that help the OCSP client verify the responder's signature. - I understand that it is not mandatory to send the OCSP response signer certificate in the OCSP response. So in such cases, where to find the OCSP response signer certificate? That is my question. with regards, Saravanan ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
