Persistent connections

[Geetha_Priya]

Hi,

 

We use OpenSSL version 0.9.8b. Does it support persistent connections
when used with HTTP1.1 proxies.

When I integrate my proxy [that uses openssl libraries] with squid and I
try to access web pages I get a popup on my browser saying <<< you have
chosen to open http://weblink   Which is a bin file" and
provides options to save or cancel >>> .

 

Also the sub requests for other content (like image.jpg) is not
triggered. Hence I would like to know about persistent connection
options.

 

Please help

 

Thanks and Regards

Geetha



DISCLAIMER:
This email (including any attachments) is intended for the sole use of the 
intended recipient/s and may contain material that is CONFIDENTIAL AND PRIVATE 
COMPANY INFORMATION. Any review or reliance by others or copying or 
distribution or forwarding of any or all of the contents in this message is 
STRICTLY PROHIBITED. If you are not the intended recipient, please contact the 
sender by email and delete all copies; your cooperation in this regard is 
appreciated.

Signature validation in certificates

[Geetha_Priya]

I have read numerous certification related docs. Being new to this
technology I don't find any material detailing the manual certificate
validation [even the faq on the same heading ] specially verifying key
part.  I also went through verify.c in openssl but key verification is
lost amongst the APIs. Here is my understanding on certificate
validation

 

A root certificate [signed by CA] comprises of  version, serial num,
issuer and subject details, public key algorithm details and a signature
which is hash of the rest of cert details further encrypted using
private key. This root cert is installed by browsers automatically. The
web servers have their certificates signed by these CA.

 

When a https site id accessed , the  server sends a server certificate
that contains most of the above details (except for changed subject
name/validity etc.)along with the signature and a RSA public key

 

Now for certificate validation:

 

First we verify the credentials of issuer/common name etc.. that is
clear to me

 

Second step is to match the signature which I find a lil confusing

 

Here do you use public key to decrypt the signature portion of your root
certificate and compare it with,

 the decrypted portion of server certificate (decrypted with public key
that appears in server certificate). Does this sound right?

 

The root certificate has public key and signature and so does the server
certificate. 

 

Please clarify as I am manually trying to verify certificates.

Any other C files within openssl which talks the details about signature
validation.

 

Thanks for your help

Regards

Geetha

 



DISCLAIMER:
This email (including any attachments) is intended for the sole use of the 
intended recipient/s and may contain material that is CONFIDENTIAL AND PRIVATE 
COMPANY INFORMATION. Any review or reliance by others or copying or 
distribution or forwarding of any or all of the contents in this message is 
STRICTLY PROHIBITED. If you are not the intended recipient, please contact the 
sender by email and delete all copies; your cooperation in this regard is 
appreciated.

Signature validation in certificates

[Geetha_Priya]

I have read numerous certification related docs. Being new to this technology I 
don't find any material detailing the manual certificate validation [even the 
faq on the same heading ] specially verifying key part.  I also went through 
verify.c in openssl but key verification is lost amongst the APIs. Here is my 
understanding on certificate validation

A root certificate [signed by CA] comprises of  version, serial num, issuer and 
subject details, public key algorithm details and a signature which is hash of 
the rest of cert details further encrypted using private key. This root cert is 
installed by browsers automatically. The web servers have their certificates 
signed by these CA.

When a https site id accessed , the  server sends a server certificate that 
contains most of the above details (except for changed subject name/validity 
etc.)along with the signature and a RSA public key

Now for certificate validation:

First we verify the credentials of issuer/common name etc.. that is clear to me

Second step is to match the signature which I find a lil confusing

Here do you use public key to decrypt the signature portion of your root 
certificate and compare it with,
 the decrypted portion of server certificate (decrypted with public key that 
appears in server certificate). Does this sound right?

The root certificate has public key and signature and so does the server 
certificate. 

Please clarify as I am manually trying to verify certificates.
Any other C files within openssl which talks the details about signature 
validation.

Thanks for your help
Regards
Geetha



DISCLAIMER:
This email (including any attachments) is intended for the sole use of the 
intended recipient/s and may contain material that is CONFIDENTIAL AND PRIVATE 
COMPANY INFORMATION. Any review or reliance by others or copying or 
distribution or forwarding of any or all of the contents in this message is 
STRICTLY PROHIBITED. If you are not the intended recipient, please contact the 
sender by email and delete all copies; your cooperation in this regard is 
appreciated.
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   [EMAIL PROTECTED]

RE: Signature validation in certificates

[Geetha_Priya]

Thanks Dominique. I guess the openssl verify does these steps to actually 
verify if an incoming server certificate compares to a root certificate.

Regards
Geetha

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dominique Lohez
Sent: Wednesday, July 09, 2008 7:33 PM
To: openssl-users@openssl.org
Subject: Re: Signature validation in certificates



The signature checkingwork like this

The SIGNER ( CA   or SERVER )   build a digest  with an appropriate
algorithm
then he encrypt the digest with its private key

Within the certificate you know the digest algorithm so you can build
this digest
and then you  decrypt thi sdsignature  with the public key of  the
signer , this must  be identical to the digest


I hope this helps

Dominique LOHEZ

Geetha_Priya a écrit :
> I have read numerous certification related docs. Being new to this technology 
> I don't find any material detailing the manual certificate validation [even 
> the faq on the same heading ] specially verifying key part.  I also went 
> through verify.c in openssl but key verification is lost amongst the APIs. 
> Here is my understanding on certificate validation
>
> A root certificate [signed by CA] comprises of  version, serial num, issuer 
> and subject details, public key algorithm details and a signature which is 
> hash of the rest of cert details further encrypted using private key. This 
> root cert is installed by browsers automatically. The web servers have their 
> certificates signed by these CA.
>
> When a https site id accessed , the  server sends a server certificate that 
> contains most of the above details (except for changed subject name/validity 
> etc.)along with the signature and a RSA public key
>
> Now for certificate validation:
>


> First we verify the credentials of issuer/common name etc.. that is clear to 
> me
>
> Second step is to match the signature which I find a lil confusing
>
> Here do you use public key to decrypt the signature portion of your root 
> certificate and compare it with,
>  the decrypted portion of server certificate (decrypted with public key that 
> appears in server certificate). Does this sound right?
>
> The root certificate has public key and signature and so does the server 
> certificate.
>
> Please clarify as I am manually trying to verify certificates.
> Any other C files within openssl which talks the details about signature 
> validation.
>
> Thanks for your help
> Regards
> Geetha
>
>
>
> DISCLAIMER:
> This email (including any attachments) is intended for the sole use of the 
> intended recipient/s and may contain material that is CONFIDENTIAL AND 
> PRIVATE COMPANY INFORMATION. Any review or reliance by others or copying or 
> distribution or forwarding of any or all of the contents in this message is 
> STRICTLY PROHIBITED. If you are not the intended recipient, please contact 
> the sender by email and delete all copies; your cooperation in this regard is 
> appreciated.
> __
> OpenSSL Project http://www.openssl.org
> User Support Mailing Listopenssl-users@openssl.org
> Automated List Manager   [EMAIL PROTECTED]
>
>
>
>


--
Dr Dominique LOHEZ
ISEN
41, Bd Vauban
F59046 LILLE
France

Phone : +33 (0)3 20 30 40 71
Email: [EMAIL PROTECTED]

__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   [EMAIL PROTECTED]


DISCLAIMER:
This email (including any attachments) is intended for the sole use of the 
intended recipient/s and may contain material that is CONFIDENTIAL AND PRIVATE 
COMPANY INFORMATION. Any review or reliance by others or copying or 
distribution or forwarding of any or all of the contents in this message is 
STRICTLY PROHIBITED. If you are not the intended recipient, please contact the 
sender by email and delete all copies; your cooperation in this regard is 
appreciated.
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   [EMAIL PROTECTED]

RE: Signature validation in certificates

[Geetha_Priya]

Hi Patrik,

Thanks for your detailed response. It certainly helped my understanding. I did 
refer RFC3280 but missed out on 5280. Will refer it and like you said manually 
validating certificates might be risky.

Thanks and Regards
Geetha

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Patrick Patterson
Sent: Wednesday, July 16, 2008 1:31 AM
To: openssl-users@openssl.org
Subject: Re: Signature validation in certificates

Hi Geetha:

Certificate Validation is explained in detail in RFC3280 (and, more up to
date, RFC5280).

More replies inline:

On July 9, 2008 03:17:56 am Geetha_Priya wrote:
>
> A root certificate [signed by CA] comprises of  version, serial num,
> issuer and subject details, public key algorithm details and a signature
> which is hash of the rest of cert details further encrypted using
> private key. This root cert is installed by browsers automatically. The
> web servers have their certificates signed by these CA.
>
No - a Root certificate is a self signed certificate - usually belonging to a
Certificate Authority, but possibly made up by Bob in accounting. In order to
find out if you trust this certificate, you have to either:

1) Explicitly trust it, because it came with your browser, and you trust
Microsoft, Mozilla, Apple, Opera, or the KDE folk.

2) Make an informed trust decision, and go through some process to decide what
to base your trust of this Certificate on. This usually means to find out the
Certificate Authority that is represented by this certificate, read the
certificate policy that this certificate was issued under, and ask them to
produce an audit result from a recognised auditor that they are complying
with their certificate policy.


>
>
> When a https site id accessed , the  server sends a server certificate
> that contains most of the above details (except for changed subject
> name/validity etc.)along with the signature and a RSA public key
>
>
Well, the server sends a certificate that has the Subject name as the name of
the server, and the Issuer as the name of the person or organisation that
signed the server's certificate. There may be LOTS of other details
included - see RFC5280 for the full list. The full function of verifying
validity is called Path Discovery and Validation (PDVal for short)

>
> Now for certificate validation:
>
>
>
> First we verify the credentials of issuer/common name etc.. that is
> clear to me
>
>
This is actually the last step - you only want to match the Subject to your
access control list. The issuer is only used to figure out whether you can
trust the assertions made in the certificate.

>
> Second step is to match the signature which I find a lil confusing
>
The signature is verified by taking the public key of the Issuer (usually
found in the Issuer's certificate) and doing a signature verification
function on the hash of the Subject Certificate contents.

Sometimes, the Root (also called a trust anchor, or trusted root) signs the
subject certificates itself:

ROOT -> Subject


It's likely though, that to get to a root, there may be a chain of
verifications to do:

ROOT -> Intermediate CA -> Subject

There may be also a complex trust fabric to follow to get back to a root that
you trust:

Trusted Root -> Bridge CA -> Other Root -> Intermediate CA -> Subject (Server
Cert)

Finding out about all of these is called "Trust Path Discovery".

Once you have a path to a trusted anchor (root), then you have to (as a
minimum):

Verify Validity periods of all certificates in the chain (Valid Before, Valid
Until fields)

Verify if any of the Certificates have been revoked (By Checking CRL and/or
OCSP - watch out - these are also signed artifacts, and you have to perform
PDVal on them too - and it may be recursive :)

Verify the Key Usage and Extended Key Usage Fields.

Make sure that you process all critical fields in all certificates.

Validate that the certificates were issued according to a certificate policy
that you trust, or one that maps to a certificate policy that you trust.

Verify that everyone is respecting their policy and name constraints.

This is called Path validation.

Most of these functions (but not all) are handled by the "openssl verify"
command. If you have a simple trust fabric, then you should be able to use
this command to verify certificates.

If you are writing code to do this, then I would recommend not doing it
yourself, and just using the X509_verify() functions that are built into
OpenSSL.

For some more information on the basics of PKI, and explanations of most of
what certificates are and how they work, you can see our "FingerPuppet" howto
guides to PKI:

http://www.carillon.ca/library/howtos.php

Have fun.

--
Patrick Patterson
President and Chief PKI Architect,
Carillon Information Security Inc.
http://www.carillon.ca
__