Editing Talk:1353: Heartbleed

I added an explanation for the punchline. [[User:ImVeryAngryItsNotButter|ImVeryAngryItsNotButter]] ([[User talk:ImVeryAngryItsNotButter|talk]]) 16:13, 10 April 2014 (UTC)

I added a transcript, if I messed up on anything, I'm sorry! [[Special:Contributions/173.245.55.73|173.245.55.73]] 06:08, 9 April 2014 (UTC)
:Thanks for the transcript! (nothing seems messed up) [[Special:Contributions/141.101.88.206|141.101.88.206]] 06:41, 9 April 2014 (UTC)
::But wait! You forgot a comma! (It's okay, I fixed it :) ) [[Special:Contributions/108.162.216.67|108.162.216.67]] 06:47, 9 April 2014 (UTC)

The alt-text contains a reference to the scene "Tears in the rain" of Blade Runner [[Special:Contributions/173.245.49.90|173.245.49.90]] 06:19, 9 April 2014 (UTC)

Is Explainxkcd using Open SSL? [[User:Jonv4n|Jonv4n]] ([[User talk:Jonv4n|talk]]) 06:56, 9 April 2014 (UTC)

I'd just like to take this moment to say that even though you probably don't have anything of value stored here, Explain xkcd is good on the Heartbleed front. Not using any of the affected software because the data we handle isn't private at all probably helps with that. And yes, Mediawiki hashes your passwords before they're sent. '''[[User:Davidy22|<u>{{Color|#707|David}}<font color=#070 size=3>y</font></u><font color=#508 size=4>²²</font>]]'''[[User talk:Davidy22|<tt>[talk]</tt>]] 07:18, 9 April 2014 (UTC)

: Davidy22 - While your first point was correct (explainxkcd isn't vulnerable to heartbleed as explainxkcd doesn't any encryption -- everything starts being sent in plaintext over the net), your second point is wrong.  As anyone with wireshark can verify (or using your web browsers' developer tools), when you login to explainxkcd from `http://www.explainxkcd.com/wiki/index.php?title=Special:UserLogin&returnto=Main+Page`, you make a POST request to `/wiki/index.php` that contains as a POST variable your user name (in the POST variable wpName), and your password (in the POST variable wpPassword), both sent in plaintext.  Granted it probably is stored in the database hashed (hopefully with a unique salt and a good hash algorithm), it is readable by any network eavesdropper.  Not really a problem though, if you don't reuse passwords or mind if your account here was compromised.  [[User:Jimbob|Jimbob]] ([[User talk:Jimbob|talk]]) 22:38, 9 April 2014 (UTC)

Have the following from [http://www.openssl.org/news/secadv_20140407.txt OpenSSL Bug Report]
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]
TLS heartbeat read overrun (CVE-2014-0160)

A missing bounds check in the handling of the TLS heartbeat extension can be
used to reveal up to 64k of memory to a connected client or server.

Only 1.0.1 and 1.0.2-beta releases of OpenSSL are affected including
1.0.1f and 1.0.2-beta1.

Thanks for Neel Mehta of Google Security for discovering this bug and to
Adam Langley <agl@chromium.org> and Bodo Moeller <bmoeller@acm.org> for
preparing the fix.

Affected users should upgrade to OpenSSL 1.0.1g. Users unable to immediately
upgrade can alternatively recompile OpenSSL with -DOPENSSL_NO_HEARTBEATS.

1.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)

: 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)
@@ Line 40: / Line 40: @@
 "
 ''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)
-::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".[[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)