Re: [openssl-dev] [openssl-users] Removing obsolete crypto from OpenSSL 1.1 - seeking feedback

[Benjamin Kaduk]

On 11/18/2015 07:05 AM, Hubert Kario wrote:
> So, a full CAdES-A, XAdES-A or PAdES-A implementation _needs_ to support 
> both relatively modern TLS with user certificates, preferably the newest 
> cryptosystems and hashes as well as the oldest ones that were 
> standardised and used.
>
> That means that old algorithms MUST remain in OpenSSL as supported 
> functionality. It may require linking to a specific library to make the 
> EVP* with old ciphers, MACs, etc. work, but they MUST NOT be removed 
> from it completely, definitely not before at least 50 years _after_ they 
> became obsolete and broken.
>

There seems to be a logical leap between these two paragraphs.  Why is
it necessary that OpenSSL be the only cryptographic library used by
CAdES-A/etc. implementations?  Is it in fact even necessary that only a
single version of a single cryptographic library be used for such
software?  While OpenSSL may try to be a general-purpose crypto library,
when a software has stringent or unusual crypto requirements, it seems
reasonable that such a software may need to involve unusual implementations.

I do not believe that OpenSSL has promised anywhere that it will support
this sort of use case.

-Ben
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] OpenSSL as OCSP server (responder) as multithreading daemon !

[CpServiceSPb .]

> We have no plans to do this.
May be will put it into your plans ?

> It would be nice to see something like this as a new open-source project.

I am for that by both hands. Burt unfortunatelly I am not a well skilled
programmer/developer and I will not do it.
I can give the task for that for developers only.
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] OpenSSL as OCSP server (responder) as multithreading daemon !

[Salz, Rich]

Ø  > We have no plans to do this.
May be will put it into your plans ?

Doubtful.  We have lots of other work to do.  Writing a full-strength 
database-backed OCSP responder is outside of our interests.
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] [openssl.org #4147] TSA: SHA-1 update

[Michal Bozon via RT]

OpenSSL TSA (ts) code is still using SHA-1 message digest algorithm,
in even two ways:

 * as default message digest algo in the time-stamp query (by default)
 * in the time-stamp reply/token signature (hard-coded)

This pull request attempts to fix it:
https://github.com/openssl/openssl/pull/474


regards,
Michal Bozon

___
openssl-bugs-mod mailing list
openssl-bugs-...@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-bugs-mod

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

[openssl-dev] [openssl.org #4148] PCKS1 type 1 Padding check error

[Özgan , Tolgahan Jonas via RT]

Dear List,
I have found a BUG in the function
" RSA_padding_check_PKCS1_type_1 "

The bug is reproducible in OpenSSL Versions 1.0.1e , 1.0.1p ,  1.0.1k and also 
in 1.0.2d (these are the versions I've tried) . After Inspecting the source 
code the bug can still be found in the actual development branch.

Description:
When a correctly formatted PKCS1 Type 1 data string is given to the method " 
RSA_padding_check_PKCS1_type_1 " it always results in:

OpenSSLError: Code:67567722 in file:rsa_pk1.c line:102.
OpenSSLError: Error Message: error:0407006A:rsa 
routines:RSA_padding_check_PKCS1_type_1:block type is not 01

Even when the message was originally padded by the corresponding OpenSSL 
Padding Function " RSA_padding_add_PKCS1_type_1"  the same error occurs.

Cause:
In the File crypto/rsa/rsa_pk1.c
Following check is made to determine the Block type of the padding string
const unsigned char *p;
p=from;
if ((num != (flen+1)) || (*(p++) != 01))

the pointer p is incremented after the check therefore p is always the first 
octet of the padded string. In the Case of PKCS1 type 1 padding  always p=0, 
hence the error.
Notes:
Changing the check  to
if ((num != (flen+1)) || (*(++p) != 01))
results also in a failure since the next check of p expects p to be "0xff" .

Fix:
Adding an increment before the check:

const unsigned char *p;
p=from;
p++;  //NEW
if ((num != (flen+1)) || (*(p++) != 01))

fixes the problem.

Question:
What does the the first part of the Check , check exactly ?
Ie:
num != (flen+1)
 num being rsa_size and flen the length of the buffer where the message is 
stored.

Thanks




Dipl.-Inf T. Jonas Özgan
Cyber Analysis & Defense Department
Fraunhofer Institute for Communication, Information Processing and Ergonomics 
(FKIE)
Fraunhoferstr. 20 | 53343 Wachtberg  | Germany
Tel: +49 228 9435-513 | Fax +49 228 9435-685
http://www.fkie.fraunhofer.de


___
openssl-bugs-mod mailing list
openssl-bugs-...@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-bugs-mod___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [openssl-users] Removing obsolete crypto from OpenSSL 1.1 - seeking feedback

[Blumenthal, Uri - 0553 - MITLL]

On 11/18/15, 12:12 , "openssl-dev on behalf of Benjamin Kaduk"
 wrote:

>On 11/18/2015 07:05 AM, Hubert Kario wrote:
>> So, a full CAdES-A, XAdES-A or PAdES-A implementation _needs_ to
>>support 
>> both relatively modern TLS with user certificates, preferably the
>>newest 
>> cryptosystems and hashes as well as the oldest ones that were
>> standardised and used.
>>
>> That means that old algorithms MUST remain in OpenSSL as supported
>> functionality. It may require linking to a specific library to make the
>> EVP* with old ciphers, MACs, etc. work, but they MUST NOT be removed
>> from it completely, definitely not before at least 50 years _after_
>>they 
>> became obsolete and broken.
>
>There seems to be a logical leap between these two paragraphs.  Why is
>it necessary that OpenSSL be the only cryptographic library used by
>CAdES-A/etc. implementations?

Because it used to be the only real game in town, and *people learned to
rely upon it*.

>Is it in fact even necessary that only a
>single version of a single cryptographic library be used for such
>software? 

No, of course not. But after letting people depend on this “single
cryptographic library” for many years, telling them “too bad” isn’t very
nice.

>While OpenSSL may try to be a general-purpose crypto library,
>when a software has stringent or unusual crypto requirements, it seems
>reasonable that such a software may need to involve unusual
>implementations.

The requirements did not change. What changed was the maintainers
expressing their desire to stop supporting some of them.

>I do not believe that OpenSSL has promised anywhere that it will support
>this sort of use case.

Implicitly, by providing that kind of service for so long. And explicitly,
as pointed out by Hubert:

From the main web page of project:

The OpenSSL Project is a collaborative effort to develop a 
robust,
commercial-grade, *full-featured*, and Open Source toolkit
implementing the Transport Layer Security (TLS) and Secure 
Sockets
Layer (SSL) protocols as well as a full-strength *general 
purpose*
*cryptography library* .



smime.p7s
Description: S/MIME cryptographic signature
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [openssl-users] Removing obsolete crypto from OpenSSL 1.1 - seeking feedback

[Hubert Kario]

On Wednesday 18 November 2015 11:12:59 Benjamin Kaduk wrote:
> On 11/18/2015 07:05 AM, Hubert Kario wrote:
> > So, a full CAdES-A, XAdES-A or PAdES-A implementation _needs_ to
> > support both relatively modern TLS with user certificates,
> > preferably the newest cryptosystems and hashes as well as the
> > oldest ones that were standardised and used.
> > 
> > That means that old algorithms MUST remain in OpenSSL as supported
> > functionality. It may require linking to a specific library to make
> > the EVP* with old ciphers, MACs, etc. work, but they MUST NOT be
> > removed from it completely, definitely not before at least 50 years
> > _after_ they became obsolete and broken.
> 
> There seems to be a logical leap between these two paragraphs.  Why is
> it necessary that OpenSSL be the only cryptographic library used by
> CAdES-A/etc. implementations?  Is it in fact even necessary that only
> a single version of a single cryptographic library be used for such
> software? 
>
> While OpenSSL may try to be a general-purpose crypto
> library, when a software has stringent or unusual crypto
> requirements, it seems reasonable that such a software may need to
> involve unusual implementations.
> 
> I do not believe that OpenSSL has promised anywhere that it will
> support this sort of use case.

From the main web page of project:

  The OpenSSL Project is a collaborative effort to develop a robust,   
  commercial-grade, *full-featured*, and Open Source toolkit 
  implementing the Transport Layer Security (TLS) and Secure Sockets 
  Layer (SSL) protocols as well as a full-strength *general purpose* 
  *cryptography library* .

(emphasis mine)

-- 
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic

signature.asc
Description: This is a digitally signed message part.
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] PBE_UNICODE

[Dmitry Belyavsky]

Hello OpenSSL Team,

I use the openssl 1.0.2d.

There is a commented out definition of the PBE_UNICODE define in the file
pkcs12.h
I expected it to be necessary for correct processing of the Cyrillic
symbols in PKCS12 passwords, but my test shows that the password is
correctly processed when the PBE_UNICODE is undefined and locale is set to
ru_RU.utf8.

Do I miss something or this variable and corresponding #ifdef may be
eliminated?

Thank you!

-- 
SY, Dmitry Belyavsky
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] OpenSSL as OCSP server (responder) as multithreading daemon !

[CpServiceSPb .]

Is it possible to include at nearest developing plans ability of running
OpenSSL at Ocsp responder mode as multithreading daemon (Linux) and service
(Windows)  ?
That is to add -daemon switch in conjunction with ocsp and -index (which
causes OSSL acting as responder) .
And in such way OSSL will serve many incoming OCSP requests in background
mode got at listening port in additional current OCSP functional.
To improve usability at such ocps reponder daemon mode txt DB file shoud be
used;
Format of the DB have to be look like index.txt and as followng:

StatusSerial  Root Cert
rkey parameterrcert parameter
V1021  /path/Root.pem
/path/ocspserver.pem   /path/ocspserver.pem
V3565  /path/Root.pem
/path/ocspserver2.pem/path/ocspserver2.pem

So, second parameter is serial number of certificate in OCSP request, Root
cert equals -CAfile parameter of openssl ocsp -CAfile, rkey parameter &
rcert parameter are respectivelly -rkey and rcert parameters.

As follows, multiple certificate "checking" rules can be at Db.

And when OSSL starts it loads this DB to a memory, parses requests (as now)
and uses CAfile, rkey and rcert from DB for certificate with appropriate
serial.


Alex.
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [openssl.org #4144] patch: Use '__sun' instead of 'sun' for strict ISO conforming, compiler/options

[Richard PALO via RT]

Le 17/11/15 19:47, Kurt Roeckx via RT a écrit :
> On Tue, Nov 17, 2015 at 06:33:22PM +, Richard PALO via RT wrote:
>>
>> Strict ISO conforming compilers don't define 'sun', only __sun.
> 
> Ah, I clearly misunderstood your earlier message.
> 
> 
> Kurt
> 

Sorry, perhaps it was a bit terse...

Here's a comparison of 'with extensions' and then 'strict' for studio

> richard@omnis:/home/richard$ /opt/solarisstudio12.4/bin/cc -xc99 -E 
> -xdumpmacros /dev/null |& egrep  'sun|svr4|SVR4'
> #define __SVR4 1
> #define __sun 1
> #define sun 1
> richard@omnis:/home/richard$ /opt/solarisstudio12.4/bin/cc -Xc -xc99 -E 
> -xdumpmacros /dev/null |& egrep  'sun|svr4|SVR4'
> #define __SVR4 1
> #define __sun 1

and for gcc (or clang)

> richard@omnis:/home/richard$ /opt/gcc-4.8.1/bin/gcc -std=gnu99 -E -dM - 
>  #define __SVR4 1
> #define __sun 1
> #define sun 1
> #define __sun__ 1
> #define __svr4__ 1
> richard@omnis:/home/richard$ /opt/gcc-4.8.1/bin/gcc -std=c99 -E -dM - 
>  #define __SVR4 1
> #define __sun 1
> #define __sun__ 1
> #define __svr4__ 1

-- 
Richard PALO


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

Re: [openssl-dev] OpenSSL as OCSP server (responder) as multithreading daemon !

[Salz, Rich]

Ø  Is it possible to include at nearest developing plans ability of running 
OpenSSL at Ocsp responder mode as multithreading daemon (Linux) and service 
(Windows)  ?

We have no plans to do this.

It would be nice to see something like this as a new open-source project.

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

Re: [openssl-dev] [openssl.org #4145] Enhancement: patch to support s_client -starttls http

[William A. Rowe Jr. via RT]

Please note my typo identified by a dev at httpd, Yann...

A little note, probably some missing == here:
+else if (meth = TLSv1_2_client_method())
+BIO_printf(fbio, "Upgrade: TLS/1.2\r\n");
+else if (meth = TLSv1_1_client_method())
+BIO_printf(fbio, "Upgrade: TLS/1.1\r\n");
+else if (meth = TLSv1_client_method())
+BIO_printf(fbio, "Upgrade: TLS/1.0\r\n");

Revised patch attached.

diff --git a/apps/s_client.c b/apps/s_client.c
index f80711f..4fe908d 100644
--- a/apps/s_client.c
+++ b/apps/s_client.c
@@ -403,7 +403,7 @@ static void sc_usage(void)
 BIO_printf(bio_err,
" 'prot' defines which one to assume.  Currently,\n");
 BIO_printf(bio_err,
-   " only \"smtp\", \"pop3\", \"imap\", \"ftp\" and \"xmpp\"\n");
+   " only \"smtp\", \"pop3\", \"imap\", \"ftp\", \"xmpp\" and \"http\"\n");
 BIO_printf(bio_err, " are supported.\n");
 #ifndef OPENSSL_NO_ENGINE
 BIO_printf(bio_err,
@@ -655,7 +655,8 @@ enum {
 PROTO_POP3,
 PROTO_IMAP,
 PROTO_FTP,
-PROTO_XMPP
+PROTO_XMPP,
+PROTO_HTTP
 };
 
 int MAIN(int, char **);
@@ -1077,6 +1078,8 @@ int MAIN(int argc, char **argv)
 starttls_proto = PROTO_FTP;
 else if (strcmp(*argv, "xmpp") == 0)
 starttls_proto = PROTO_XMPP;
+else if (strcmp(*argv, "http") == 0)
+starttls_proto = PROTO_HTTP;
 else
 goto bad;
 }
@@ -1632,8 +1635,7 @@ int MAIN(int argc, char **argv)
 BIO_free(fbio);
 BIO_printf(sbio, "AUTH TLS\r\n");
 BIO_read(sbio, sbuf, BUFSIZZ);
-}
-if (starttls_proto == PROTO_XMPP) {
+} else if (starttls_proto == PROTO_XMPP) {
 int seen = 0;
 BIO_printf(sbio, "= 2 && mbuf[0] != '\r' && mbuf[1] != '\n');
+(void)BIO_flush(fbio);
+BIO_pop(fbio);
+BIO_free(fbio);
+if (!foundit)
+BIO_printf(bio_err,
+   "Server response was not 101 Switching Protocols"
+   " try anyway...\n");
 }
 
 for (;;) {
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [openssl-users] Removing obsolete crypto from OpenSSL 1.1 - seeking feedback

[Viktor Dukhovni]

On Wed, Nov 18, 2015 at 02:34:41PM -0600, Benjamin Kaduk wrote:

> > No, of course not. But after letting people depend on this “single
> > cryptographic library” for many years, telling them “too bad” isn’t very
> > nice.
> 
> I guess I'm just having a hard time wrapping my head around why, upon
> hearing that the volunteer-run project is giving years' advance notice
> that certain features will be removed, the response is insistence that
> everything must remain supported forever, instead of using the advance
> notice to investigate alternatives.  Volunteers should be allowed to
> ease up when they need to, after all.

Culture-clash.  Security culture says everything remotely weak must
go, but release-engineering culture emphasizes compatibilty.  The
crypto library is more of a systems component, not a security
component.  The SSL library is more of a security component than
a systems component, and has algorithm negotiation.

For example, Linux never breaks user-land, you can do all kinds of
things inside the kernel, but user-land software (for a fixed libc)
that worked before is going to continue working on new kernels.
Doing that since 1991 or so.

SunOS libc implemented multiple ABIs to ensure application
compatibility.  Many other operating systems do likewise.

For better or worse, libcrypto is part of that world.  It is a
building block library for whatever applications the users want to
use it for.  It is not a security technology in its own right.


> Surely the requirements for a general-purpose crypto library must change
> over time!  

Yes, by accretion.  And "general-purpose" does not mean "the expected
use-cases", it really means "general".

> have.  As the state of the art advances, the library must adapt to
> match, and removing components that are no longer widespread or
> essential seems a natural part of that adaptation.  The requirements are
> not an append-only list.

Except that they are, just as Linux and libc provide an append-only
set of interfaces.

> > The OpenSSL Project is a collaborative effort to develop a 
> > robust,
> > commercial-grade, *full-featured*, and Open Source toolkit
> > implementing the Transport Layer Security (TLS) and Secure 
> > Sockets
> > Layer (SSL) protocols as well as a full-strength *general 
> > purpose*
> > *cryptography library* .
> 
> 
> That text reads as if it was originally drafted 10+ years ago, when
> "full-featured" meant "we support both encryption and decryption" as
> well as "we provide both export-grade and strong crypto".  I'm sure we
> could put some updated text in if that would help clarify what exactly
> the goals of the project are.  And, as Richard notes, general-purpose
> does not mean "usable for every possible specific use case under the
> sun", it means "usable for most common things", which to me does not
> include CAdES-A and the like.

No, general purpose really means whatever purpose the user has in
mind.  The "most common things" is not "general purpose".

-- 
Viktor.
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl-dev] Fwd: OpenSSL as OCSP server (responder) as multithreading daemon !

[CpServiceSPb .]

>> We have no plans to do this. May be will put it into your plans ?
> Doubtful. We have lots of other work to do. Writing a full-strength
database-backed OCSP responder is outside of our interests.

Ok. In such situation, can you add ability of using multiple -CA, -rkey,
-rsigner parameters of trinity, at least ?
That OSSL at Ocsp responder mode could handle arrived request through all
specified parameters of trinity: -CA1, -rkey1, -rsigner1; -CA2, -rkey2,
-rsigner3 and so on ?

Besides, there is "Support Multiple CA certs in ocsp app" commit -
https://github.com/akamai/openssl/commit/7f5ed141fef8509b589b5a5601f0ec2bf5e08faf


Alex.

P. S.: I am ready to make some donation for it.
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] Fwd: OpenSSL as OCSP server (responder) as multithreading daemon !

[Salz, Rich]

Ø  Ok. In such situation, can you add ability of using multiple -CA, -rkey, 
-rsigner parameters of trinity, at least ?

Perhjaps someone will contribute a patch?
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev