Talk:1353: Heartbleed - Revision history

Beanie: y

2021-07-01T11:11:19Z

Beanie: bru

2021-07-01T11:11:03Z

bru

Beanie: who put those lines there

2021-07-01T11:10:41Z

who put those lines there

Weatherlawyer at 19:27, 9 January 2015

2015-01-09T19:27:18Z

Jezzaaaa: /* == */

2014-04-14T21:42:55Z

‎==

Jezzaaaa: /* == */

2014-04-14T21:41:27Z

‎==

Hkmaly at 10:53, 11 April 2014

2014-04-11T10:53:45Z

Jezzaaaa: /* == */

2014-04-11T00:40:17Z

‎==

Dgbrt at 22:29, 10 April 2014

2014-04-10T22:29:45Z

Jezzaaaa at 22:19, 10 April 2014

2014-04-10T22:19:26Z

@@ Line 19: / Line 19: @@
 OpenSSL Security Advisory [07 Apr 2014]
 TLS heartbeat read overrun (CVE-2014-0160)
 A missing bounds check in the handling of the TLS heartbeat extension can be

@@ Line 18: / Line 18: @@
 OpenSSL Security Advisory [07 Apr 2014]
-========================================
+TLS heartbeat read overrun (CVE-2014-0160)
 ==========================================

@@ Line 16: / Line 16: @@
 Should this be incorperated into the main explanation, and how should it be formated
 [[User:Jonv4n|Jonv4n]] ([[User talk:Jonv4n|talk]]) 08:07, 9 April 2014 (UTC)
 OpenSSL Security Advisory [07 Apr 2014]
@@ Line 39: / Line 37: @@
 .0.2 will be fixed in 1.0.2-beta2.
 :Actually, attack is limited to data in memory of the webserver PROCESS. Even on affected computers, other applications are safe and most of disk content is safe. Not speaking about the fact that in many cases, the public-facing webserver is just proxy cache before the real ones. The real problem is if someone immediately used the revealed data - either to impersonate the server or for example found the admin password and used it to copy the database ... which DOES leave traces. I agree with Cueball: there can be worse kind of bug. In fact, I'm sure that what Edward Snowden revealed is worse, although not technically bug. -- [[User:Hkmaly|Hkmaly]] ([[User talk:Hkmaly|talk]]) 10:18, 9 April 2014 (UTC)

← Older revision		Revision as of 19:27, 9 January 2015
Line 52:		Line 52:
	:::Another attempt at explanation: server certificate is accepted because it's SIGNED by (private key of) AUTHORITY. The certificate (public key) of AUTHORITY is part of browser. So, the implicitly trusted certificates of authorities are registered/listed in browser, but no list of server certificates is needed. And yes, you need to pay for getting your certificate signed by one of those few (120?) authorities which are part of most browsers. -- [[User:Hkmaly\|Hkmaly]] ([[User talk:Hkmaly\|talk]]) 10:53, 11 April 2014 (UTC)		:::Another attempt at explanation: server certificate is accepted because it's SIGNED by (private key of) AUTHORITY. The certificate (public key) of AUTHORITY is part of browser. So, the implicitly trusted certificates of authorities are registered/listed in browser, but no list of server certificates is needed. And yes, you need to pay for getting your certificate signed by one of those few (120?) authorities which are part of most browsers. -- [[User:Hkmaly\|Hkmaly]] ([[User talk:Hkmaly\|talk]]) 10:53, 11 April 2014 (UTC)
	::::Yep, and being signed does not require being registered. So, instead of "if the certificate is registered the browser accepts it", perhaps "if the certificate is ''signed by a trusted authority'' the browser accepts it".[[User:Jezzaaaa\|Jezzaaaa]] ([[User talk:Jezzaaaa\|talk]]) 21:42, 14 April 2014 (UTC)		::::Yep, and being signed does not require being registered. So, instead of "if the certificate is registered the browser accepts it", perhaps "if the certificate is ''signed by a trusted authority'' the browser accepts it".[[User:Jezzaaaa\|Jezzaaaa]] ([[User talk:Jezzaaaa\|talk]]) 21:42, 14 April 2014 (UTC)
		+
		+	What is most remarkable in all this is the list of things that have happened to or about Robin Seggelmann. Compare enquiries and published data on him with what has occurred to Julian Assange or Edward Snowden.[[User:Weatherlawyer\|Weatherlawyer]] ([[User talk:Weatherlawyer\|talk]]) 19:27, 9 January 2015 (UTC)

@@ Line 51: / Line 51: @@
 ::You're talking about the CA certificate at the root of the trust chain.  But the certificate in ''the server sends a certificate ... if the certificate is registered'' is the server's certificate, not the CA certificate. [[User:Jezzaaaa|Jezzaaaa]] ([[User talk:Jezzaaaa|talk]]) 00:40, 11 April 2014 (UTC)
 :::Another attempt at explanation: server certificate is accepted because it's SIGNED by (private key of) AUTHORITY. The certificate (public key) of AUTHORITY is part of browser. So, the implicitly trusted certificates of authorities are registered/listed in browser, but no list of server certificates is needed. And yes, you need to pay for getting your certificate signed by one of those few (120?) authorities which are part of most browsers. -- [[User:Hkmaly|Hkmaly]] ([[User talk:Hkmaly|talk]]) 10:53, 11 April 2014 (UTC)
-::::Yep, and being signed does not require being registered. So, instead of "if the certificate is registered the browser accepts it", perhaps "if the certificate is ''signed by a trusted authority'' the browser accepts it".
+::::Yep, and being signed does not require being registered. So, instead of "if the certificate is registered the browser accepts it", perhaps "if the certificate is ''signed by a trusted authority'' the browser accepts it".[[User:Jezzaaaa|Jezzaaaa]] ([[User talk:Jezzaaaa|talk]]) 21:42, 14 April 2014 (UTC)

← Older revision		Revision as of 21:41, 14 April 2014
Line 51:		Line 51:
	::You're talking about the CA certificate at the root of the trust chain. But the certificate in ''the server sends a certificate ... if the certificate is registered'' is the server's certificate, not the CA certificate. [[User:Jezzaaaa\|Jezzaaaa]] ([[User talk:Jezzaaaa\|talk]]) 00:40, 11 April 2014 (UTC)		::You're talking about the CA certificate at the root of the trust chain. But the certificate in ''the server sends a certificate ... if the certificate is registered'' is the server's certificate, not the CA certificate. [[User:Jezzaaaa\|Jezzaaaa]] ([[User talk:Jezzaaaa\|talk]]) 00:40, 11 April 2014 (UTC)
	:::Another attempt at explanation: server certificate is accepted because it's SIGNED by (private key of) AUTHORITY. The certificate (public key) of AUTHORITY is part of browser. So, the implicitly trusted certificates of authorities are registered/listed in browser, but no list of server certificates is needed. And yes, you need to pay for getting your certificate signed by one of those few (120?) authorities which are part of most browsers. -- [[User:Hkmaly\|Hkmaly]] ([[User talk:Hkmaly\|talk]]) 10:53, 11 April 2014 (UTC)		:::Another attempt at explanation: server certificate is accepted because it's SIGNED by (private key of) AUTHORITY. The certificate (public key) of AUTHORITY is part of browser. So, the implicitly trusted certificates of authorities are registered/listed in browser, but no list of server certificates is needed. And yes, you need to pay for getting your certificate signed by one of those few (120?) authorities which are part of most browsers. -- [[User:Hkmaly\|Hkmaly]] ([[User talk:Hkmaly\|talk]]) 10:53, 11 April 2014 (UTC)
		+	::::Yep, and being signed does not require being registered. So, instead of "if the certificate is registered the browser accepts it", perhaps "if the certificate is ''signed by a trusted authority'' the browser accepts it".

← Older revision		Revision as of 10:53, 11 April 2014
Line 50:		Line 50:
	:Nope, you have to pay for it. The browser trusts that few sites and accepts the certificate silently. Otherwise you do get that popup to accept or deny. --[[User:Dgbrt\|Dgbrt]] ([[User talk:Dgbrt\|talk]]) 22:29, 10 April 2014 (UTC)		:Nope, you have to pay for it. The browser trusts that few sites and accepts the certificate silently. Otherwise you do get that popup to accept or deny. --[[User:Dgbrt\|Dgbrt]] ([[User talk:Dgbrt\|talk]]) 22:29, 10 April 2014 (UTC)
	::You're talking about the CA certificate at the root of the trust chain. But the certificate in ''the server sends a certificate ... if the certificate is registered'' is the server's certificate, not the CA certificate. [[User:Jezzaaaa\|Jezzaaaa]] ([[User talk:Jezzaaaa\|talk]]) 00:40, 11 April 2014 (UTC)		::You're talking about the CA certificate at the root of the trust chain. But the certificate in ''the server sends a certificate ... if the certificate is registered'' is the server's certificate, not the CA certificate. [[User:Jezzaaaa\|Jezzaaaa]] ([[User talk:Jezzaaaa\|talk]]) 00:40, 11 April 2014 (UTC)
		+	:::Another attempt at explanation: server certificate is accepted because it's SIGNED by (private key of) AUTHORITY. The certificate (public key) of AUTHORITY is part of browser. So, the implicitly trusted certificates of authorities are registered/listed in browser, but no list of server certificates is needed. And yes, you need to pay for getting your certificate signed by one of those few (120?) authorities which are part of most browsers. -- [[User:Hkmaly\|Hkmaly]] ([[User talk:Hkmaly\|talk]]) 10:53, 11 April 2014 (UTC)

← Older revision		Revision as of 00:40, 11 April 2014
Line 49:		Line 49:
	''If the certificate is registered the browser accepts it.'' This is incorrect. Server certificates aren't accepted because they're registered, they're accepted because they can prove a chain of trust up to a CA certificate which is explicitly trusted. Ironically, certificates only need to be registered when they're revoked (on a CRL - certificate revocation list). The whole idea of the digital certificate system we use is that of federated trust, which requires no online lookup to validate a certificate. [[User:Jezzaaaa\|Jezzaaaa]] ([[User talk:Jezzaaaa\|talk]]) 22:19, 10 April 2014 (UTC)		''If the certificate is registered the browser accepts it.'' This is incorrect. Server certificates aren't accepted because they're registered, they're accepted because they can prove a chain of trust up to a CA certificate which is explicitly trusted. Ironically, certificates only need to be registered when they're revoked (on a CRL - certificate revocation list). The whole idea of the digital certificate system we use is that of federated trust, which requires no online lookup to validate a certificate. [[User:Jezzaaaa\|Jezzaaaa]] ([[User talk:Jezzaaaa\|talk]]) 22:19, 10 April 2014 (UTC)
	:Nope, you have to pay for it. The browser trusts that few sites and accepts the certificate silently. Otherwise you do get that popup to accept or deny. --[[User:Dgbrt\|Dgbrt]] ([[User talk:Dgbrt\|talk]]) 22:29, 10 April 2014 (UTC)		:Nope, you have to pay for it. The browser trusts that few sites and accepts the certificate silently. Otherwise you do get that popup to accept or deny. --[[User:Dgbrt\|Dgbrt]] ([[User talk:Dgbrt\|talk]]) 22:29, 10 April 2014 (UTC)
		+	::You're talking about the CA certificate at the root of the trust chain. But the certificate in ''the server sends a certificate ... if the certificate is registered'' is the server's certificate, not the CA certificate. [[User:Jezzaaaa\|Jezzaaaa]] ([[User talk:Jezzaaaa\|talk]]) 00:40, 11 April 2014 (UTC)

← Older revision		Revision as of 22:29, 10 April 2014
Line 48:		Line 48:
	"		"
	''If the certificate is registered the browser accepts it.'' This is incorrect. Server certificates aren't accepted because they're registered, they're accepted because they can prove a chain of trust up to a CA certificate which is explicitly trusted. Ironically, certificates only need to be registered when they're revoked (on a CRL - certificate revocation list). The whole idea of the digital certificate system we use is that of federated trust, which requires no online lookup to validate a certificate. [[User:Jezzaaaa\|Jezzaaaa]] ([[User talk:Jezzaaaa\|talk]]) 22:19, 10 April 2014 (UTC)		''If the certificate is registered the browser accepts it.'' This is incorrect. Server certificates aren't accepted because they're registered, they're accepted because they can prove a chain of trust up to a CA certificate which is explicitly trusted. Ironically, certificates only need to be registered when they're revoked (on a CRL - certificate revocation list). The whole idea of the digital certificate system we use is that of federated trust, which requires no online lookup to validate a certificate. [[User:Jezzaaaa\|Jezzaaaa]] ([[User talk:Jezzaaaa\|talk]]) 22:19, 10 April 2014 (UTC)
		+	:Nope, you have to pay for it. The browser trusts that few sites and accepts the certificate silently. Otherwise you do get that popup to accept or deny. --[[User:Dgbrt\|Dgbrt]] ([[User talk:Dgbrt\|talk]]) 22:29, 10 April 2014 (UTC)

← Older revision		Revision as of 22:19, 10 April 2014
Line 45:		Line 45:

	: Hkmaly -- Completely agree. Posted a [http://security.stackexchange.com/questions/55270/does-xkcd-com-1353-overstate-heartbleeds-capability similar discussion] at security.stackexchange.com and altered the text here to describe heartbleed in more detail. [[User:Jimbob\|Jimbob]] ([[User talk:Jimbob\|talk]]) 21:33, 9 April 2014 (UTC)		: Hkmaly -- Completely agree. Posted a [http://security.stackexchange.com/questions/55270/does-xkcd-com-1353-overstate-heartbleeds-capability similar discussion] at security.stackexchange.com and altered the text here to describe heartbleed in more detail. [[User:Jimbob\|Jimbob]] ([[User talk:Jimbob\|talk]]) 21:33, 9 April 2014 (UTC)
		+
		+	"
		+	''If the certificate is registered the browser accepts it.'' This is incorrect. Server certificates aren't accepted because they're registered, they're accepted because they can prove a chain of trust up to a CA certificate which is explicitly trusted. Ironically, certificates only need to be registered when they're revoked (on a CRL - certificate revocation list). The whole idea of the digital certificate system we use is that of federated trust, which requires no online lookup to validate a certificate. [[User:Jezzaaaa\|Jezzaaaa]] ([[User talk:Jezzaaaa\|talk]]) 22:19, 10 April 2014 (UTC)