SSL Certificate Question

Technically I think you're wrong because using TLS/SSL requires a certificate to sign and encrypt requests. You can use a self signed certificate however

Best,

-Josh
___________________________
http://byjakt.com
Currently mobile

Post by Tedd Sperling
I wrote this Friday, but forgot to send it and don't want to wait until next Friday. So, if you ppls would be so kind as to enlighten me and before I shoot my mouth off and make a complete fool of myself, please tell me if I am wrong.
I claim that a SSL Certificate is nothing more than a software instrument used by Browsers to alert users that the site they are visiting is indeed the site being reported -- IOW, the identify of the site can be trusted.
I also claim that s SSL Certificate has absolutely nothing to do with actual HTTPS communication between the Browser and the Server. For example, I can use HTTPS communication by simply placing a script in a HTTPS directory or using a .htaccess directing such -- all without a SSL Certificate.
Now, am I wrong?
Thanks,
tedd
_______________
tedd sperling
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Jasper Kips

2014-02-16 13:45:01 UTC

Yes, you are wrong. A SSL Certificate is NOT (repeat not) an identification of a site. If anything, identificationwise, it is a signed statement by the provider of the certificate, that the provider feels the Certificate details are right, and therefore the site claim to be who the Certificate says it is, could be right. The trustworthiness of the claim that the certificate that it belongs to the site serving it, and thereby establish its identity, is dependent of the trustworthiness of all certificates in the chain of certificates, all the way up to the root certificate. Thus if any certificate in the chain is compromised, the end certificate is not to be trusted. And this happens, more often than we want. Certificate authorities get compromised, more that you think. The most notable compromised authority was Diginotar.

Besides the compromise, there are CA's that do not check of the person, company or whatever, is actually representing who they claim to represent. This is common for personal certificates.

And, finally, there is a beast called 'self signed certificate'. These are mainly used to ensure encryption can take place, and do not identify the server as being the server they claim to be.

As far as encryption goes, de HTTPS encryption is based on PKI. Therefore the server has two certificates, the private one, which should never be served, and the public one, which always is served. The certificate is used for the first part of the handshake for encryption.

So, technically, you got it reversed. Although one goal of the certificate in HTTPS is identification, it is in itself not trustworthy, although lots of times it can be trustworthy. It is however needed to setup the encryption, between client and server in HTTPS.

Disclaimer, the bove is a very rough, very very rough, sketch of the role of the certificates. It is more complex than I described, but basically it is how encryption and identification work. And my state ment that the certificatie is not an identification, is a very non nuanced statement.

Jasper

tamouse pontiki

2014-02-16 15:36:28 UTC

Yes, you are wrong. A SSL Certificate is NOT (repeat not) an identification of a site. If anything, identificationwise, it is a signed statement by the provider of the certificate, that the provider feels the Certificate details are right, and therefore the site claim to be who the Certificate says it is, could be right. The trustworthiness of the claim that the certificate that it belongs to the site serving it, and thereby establish its identity, is dependent of the trustworthiness of all certificates in the chain of certificates, all the way up to the root certificate. Thus if any certificate in the chain is compromised, the end certificate is not to be trusted. And this happens, more often than we want. Certificate authorities get compromised, more that you think. The most notable compromised authority was Diginotar.
Besides the compromise, there are CA's that do not check of the person, company or whatever, is actually representing who they claim to represent. This is common for personal certificates.
And, finally, there is a beast called 'self signed certificate'. These are mainly used to ensure encryption can take place, and do not identify the server as being the server they claim to be.
As far as encryption goes, de HTTPS encryption is based on PKI. Therefore the server has two certificates, the private one, which should never be served, and the public one, which always is served. The certificate is used for the first part of the handshake for encryption.
So, technically, you got it reversed. Although one goal of the certificate in HTTPS is identification, it is in itself not trustworthy, although lots of times it can be trustworthy. It is however needed to setup the encryption, between client and server in HTTPS.
Disclaimer, the bove is a very rough, very very rough, sketch of the role of the certificates. It is more complex than I described, but basically it is how encryption and identification work. And my state ment that the certificatie is not an identification, is a very non nuanced statement.
Jasper

I know I know too little to add anything into this.

What I do want to add is that SSL Certs are useful far beyond the
Browser and [Web] Server. Perhaps more accurate is to just say client
and server, as anything can be a client, not just a browser.
Frequently, my web apps and other server apps require an encrypted
connection with another web service, using HTTPS, which case my app is
behaving as a client, but most certainly could not be called a
browser. SSL Certs are useful for p.much any web client/server
protocol that you may want encrypted; a good example is mail (IMAP,
POP, SMTP). Jabber, IRC, and other messaging protocols use them as
well.

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Tedd Sperling

2014-02-16 15:59:29 UTC

Post by Tedd Sperling
I claim that a SSL Certificate is nothing more than a software instrument used by Browsers to alert users that the site they are visiting is indeed the site being reported -- IOW, the identify of the site can be trusted.

Now I am really confused, because what I said is basically what you said, but yours was more verbose.

Can you be more specific as to why a SSL Certificate is NOT (repeat not) an identification of a site?

Cheers,

tedd

_______________
tedd sperling
***@sperling.com

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Jasper Kips

2014-02-16 16:23:30 UTC

Hi,
First we are getting way of topic.

Let me rephrase it,
I am saying the opposite. No a certificate doesn't tell you the identity of a site, nor if the claimed identity is correct.

For HTTPS a certificate, although intended that way, is not in all situations, a reliable source for establishing the identity of a site. You must not only implicitly trust de Certifying Authority, but all intermediate Authorities, between the site certificate and the root certificate. This has proven to be fallible. Both Root Authorities and Intermediate Authorities have been compromised. The net effect is that in the real world, all certificates are suspect to be false.

For example, suppose the Google Internet Authority 2 has been compromised. (Hacked is the incorrect slang term, intrusion is better). The intruder, now can create, and issue, false certificates. Now, if the intruder creates a site, say googIe.tld, and make it look like Google. Now if this site is visited, the browser will happily tell you, that the certificate is fine, and the site is what you expect it to be. Only it isn't. So, in one way it identifies the site, because the certificate is trusted in this compromised yet trusted chain of CA's, and you are actually looking at the site which has the certificate. You expect it to be Google, but it isn't.

Moreover, since intermediate certificates are issued by most OS building organizations, like Microsoft, Apple, Linux foundations, you also implicitly trust those organizations have their database of certificates up to date, and issue you with new certificates, once it is discovered certificates are compromised.

So basically, you put a whole of trust in organizations and people you don't know, or even know they exist.

And that is why I said that Certificates are not an identification.

Now I am really confused, because what I said is basically what you said, but yours was more verbose.
Can you be more specific as to why a SSL Certificate is NOT (repeat not) an identification of a site?
Cheers,
tedd
_______________
tedd sperling

Tedd Sperling

2014-02-16 16:01:48 UTC

Post by Tedd Sperling
I also claim that s SSL Certificate has absolutely nothing to do with actual HTTPS communication between the Browser and the Server. For example, I can use HTTPS communication by simply placing a script in a HTTPS directory or using a .htaccess directing such -- all without a SSL Certificate.

As far as encryption goes, de HTTPS encryption is based on PKI. Therefore the server has two certificates, the private one, which should never be served, and the public one, which always is served. The certificate is used for the first part of the handshake for encryption.
So, technically, you got it reversed. Although one goal of the certificate in HTTPS is identification, it is in itself not trustworthy, although lots of times it can be trustworthy. It is however needed to setup the encryption, between client and server in HTTPS.

So, if you do not have a SSL Certificate then you cannot have HTTPS communication -- is that your claim?

Cheers,

tedd

_______________
tedd sperling
***@sperling.com

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Jasper Kips

2014-02-16 16:25:51 UTC

Correct,
There are a plethora of sites that explain this:

http://wpengine.com/support/how-does-all-this-work-https-ssl-certificates-ca-public-and-private-keys-csrs/

is one of them. Also Google is your friend.

So, if you do not have a SSL Certificate then you cannot have HTTPS communication -- is that your claim?
Cheers,
tedd
_______________
tedd sperling
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Tedd Sperling

2014-02-16 17:07:33 UTC

Post by Jasper Kips
Correct,
http://wpengine.com/support/how-does-all-this-work-https-ssl-certificates-ca-public-and-private-keys-csrs/

I am not trying to be difficult, but the link you provided supports everything I said -- namely:

1. HTTPS just means “HTTP with SSL.” Just as “http://” means “this is a website,” seeing “https://” means “this is a website, and it’s using SSL to encrypt data and authenticate the website.

2. CERTIFICATES
A Certificate is a document that your website shows a browser to proclaim its identity. It “certifies” that the website is who it says it is.

Where did I say something different?

Cheers,

tedd

_______________
tedd sperling
***@sperling.com

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Jasper Kips

2014-02-16 18:28:27 UTC

Post by Jasper Kips
Correct,
http://wpengine.com/support/how-does-all-this-work-https-ssl-certificates-ca-public-and-private-keys-csrs/

1. HTTPS just means HTTP with SSL. Just as http:// means this is a website, seeing https:// means this is a website, and its using SSL to encrypt data and authenticate the website.

Yes and it NEEDS the certificate, which you kind of deny

You: "I also claim that s SSL Certificate has absolutely nothing to do with actual HTTPS communication between the Browser and the Server. For example, I can use HTTPS communication by simply placing a script in a HTTPS directory or using a .htaccess directing such -- all without a SSL Certificate."

And the certificate is needed, to establish the SSL, and hence then encrypted, connection.

2. CERTIFICATES
A Certificate is a document that your website shows a browser to proclaim its identity. It certifies that the website is who it says it is.

You said "IOW, the identify of the site can be trusted."
I say, the trust is misplaced.

Where did I say something different?
Cheers,
tedd
_______________
tedd sperling

No, you are not difficult, but please read your own statements.
Both your statements are the direct opposite of mine.

Tedd Sperling

2014-02-17 14:19:35 UTC

Post by Jasper Kips
http://wpengine.com/support/how-does-all-this-work-https-ssl-certificates-ca-public-and-private-keys-csrs/

1. HTTPS just means “HTTP with SSL.” Just as “http://” means “this is a website,” seeing “https://” means “this is a website, and it’s using SSL to encrypt data and authenticate the website.

Yes and it NEEDS the certificate, which you kind of deny
You: "I also claim that a SSL Certificate has absolutely nothing to do with actual HTTPS communication between the Browser and the Server. For example, I can use HTTPS communication by simply placing a script in a HTTPS directory or using a .htaccess directing such -- all without a SSL Certificate."
And the certificate is needed, to establish the SSL, and hence then encrypted, connection.

I am only questioning one doesn't need a SSL Certificate from a third party to use HTTPS communication -- is that wrong?

What is being implied by you is that a SSL Certificate exist regardless if one purchases one from a third party or not -- is that true?

Please keep in mind that I am only asking these questions to find out the truth of the matter, not to argue the details.

Cheers,

tedd
_______________
tedd sperling
***@sperling.com

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Per Jessen

2014-02-18 17:53:23 UTC

http://wpengine.com/support/how-does-all-this-work-https-ssl-certificates-ca-public-and-private-keys-csrs/

Post by Tedd Sperling
I am not trying to be difficult, but the link you provided supports
1. HTTPS just means “HTTP with SSL.” Just as “http://” means “this
is a website,” seeing “https://” means “this is a website, and it’s
using SSL to encrypt data and authenticate the website.

Yes and it NEEDS the certificate, which you kind of deny
You: "I also claim that a SSL Certificate has absolutely nothing to
do with actual HTTPS communication between the Browser and the
Server. For example, I can use HTTPS communication by simply placing
a script in a HTTPS directory or using a .htaccess directing such --
all without a SSL Certificate."
And the certificate is needed, to establish the SSL, and hence then
encrypted, connection.

I am only questioning one doesn't need a SSL Certificate from a third
party to use HTTPS communication -- is that wrong?

No, that is correct. You do need the certificate, but you may issue one
yourself.

Post by Tedd Sperling
What is being implied by you is that a SSL Certificate exist
regardless if one purchases one from a third party or not -- is that
true?

Yes.

--
Per Jessen, Zürich (5.8°C)
http://www.dns24.ch/ - your free DNS server, made in Switzerland.
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Tedd Sperling

2014-02-19 14:50:27 UTC

Gang:

Thanks, it was an interesting and fruitful discussion for me.

Cheers,

tedd
_______________
tedd sperling
***@sperling.com

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

James Moe

2014-02-16 21:46:27 UTC

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Post by Tedd Sperling
So, if you do not have a SSL Certificate then you cannot have
HTTPS communication -- is that your claim?

On the client side all you need is a browser that knows how to
handle SSL certification.
On the http server side, you must have a SSL certificate to provide
secure connections; that is how the protocol works.
The SSL certificate may be self-signed meaning that you trust
yourself but no one else may be so sanguine.
Or you may purchase a certificate that is signed by a trusted third
party who has (presumably) done due diligence to verify the claims of
your application.
From <http://en.wikipedia.org/wiki/Certificate_authority>:
"The digital certificate certifies the ownership of a public key by
the named subject of the certificate."
There is no assumption of identification.

- --
James Moe
moe dot james at sohnen-moe dot com
520.743.3936
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEARECAAYFAlMBMbMACgkQzTcr8Prq0ZP10QCgh6ADetR1lHeHsDYqTVwyD8tf
gRoAnRU5gpwWKDY5Bv7cq2EoeGRgMI2r
=t5OG
-----END PGP SIGNATURE-----

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Tedd Sperling

2014-02-17 14:19:47 UTC