A small tool to view real-world ActivityPub objects as JSON! Enter a URL
or username from Mastodon or a similar service below, and we'll send a
request with
the right
Accept
header
to the server to view the underlying object.
{
"@context": [
"https://www.w3.org/ns/activitystreams",
{
"ostatus": "http://ostatus.org#",
"atomUri": "ostatus:atomUri",
"inReplyToAtomUri": "ostatus:inReplyToAtomUri",
"conversation": "ostatus:conversation",
"sensitive": "as:sensitive",
"toot": "http://joinmastodon.org/ns#",
"votersCount": "toot:votersCount",
"litepub": "http://litepub.social/ns#",
"directMessage": "litepub:directMessage",
"Hashtag": "as:Hashtag"
}
],
"id": "https://infosec.exchange/users/ErikvanStraten/statuses/112882437562055760/replies",
"type": "Collection",
"first": {
"id": "https://infosec.exchange/users/ErikvanStraten/statuses/112882437562055760/replies?page=true",
"type": "CollectionPage",
"next": "https://infosec.exchange/users/ErikvanStraten/statuses/112882437562055760/replies?only_other_accounts=true&page=true",
"partOf": "https://infosec.exchange/users/ErikvanStraten/statuses/112882437562055760/replies",
"items": [
{
"id": "https://infosec.exchange/users/ErikvanStraten/statuses/112882463034102550",
"type": "Note",
"summary": "Detailed explanation (long)",
"inReplyTo": "https://infosec.exchange/users/ErikvanStraten/statuses/112882437562055760",
"published": "2024-07-31T18:14:52Z",
"url": "https://infosec.exchange/@ErikvanStraten/112882463034102550",
"attributedTo": "https://infosec.exchange/users/ErikvanStraten",
"to": [
"https://www.w3.org/ns/activitystreams#Public"
],
"cc": [
"https://infosec.exchange/users/ErikvanStraten/followers",
"https://beta.mstdn.cf/users/billtoulas",
"https://infosec.exchange/users/BleepingComputer"
],
"sensitive": true,
"atomUri": "https://infosec.exchange/users/ErikvanStraten/statuses/112882463034102550",
"inReplyToAtomUri": "https://infosec.exchange/users/ErikvanStraten/statuses/112882437562055760",
"conversation": "tag:infosec.exchange,2024-07-31:objectId=180890351:objectType=Conversation",
"content": "<p>Detailed explanation of what I wrote in <a href=\"https://infosec.exchange/@ErikvanStraten/112882437562055760\" target=\"_blank\" rel=\"nofollow noopener\" translate=\"no\"><span class=\"invisible\">https://</span><span class=\"ellipsis\">infosec.exchange/@ErikvanStrat</span><span class=\"invisible\">en/112882437562055760</span></a></p><p>————————<br />(1) Server certs NOT used for encryption<br />————————<br />Server certificates are not used for emcryption when using "forward secrecy" [1] - a common practice for a decade or so.</p><p>TLS sessions are encrypted using a randomly generated symmetric (e.g. AES) encryption key, for example generated by the browser.</p><p>The chicken-and-egg problem then is how to securily transfer that session key to the server over an unencrypted connection.</p><p>Before TLS v1.3, the server would automatically send it's certificate to the browser soon after the (still unencrypted) TCP/IP connection was established.</p><p>Long ago the browser would then generate the symmetric encryption key, and use the public key from the server certificate to encrypt the session key. As only the possessor of the associated private key can decrypt the result, the encrypted symmetric key could be securily transmitted over the (still unencrypted) TCP/IP connection.</p><p>Problem: if attackers or three-letter agencies capture and save encrypted session data (partially encrypted network packets), and later steal or demand a copy of the server's private key, then they can decrypt the (asymmetrically) encrypted session key, and thereafter, decrypt the entire session.</p><p>Solution (simplified), using forward secrecy [1]: for each session, the server and the browser generate an ephemerical (intended for temporary use) asymmetric keypair and exchange their public keys.</p><p>Without going into too many details [2], those ephemerical keys are used to:</p><p>• Mutually agree upon a symmetric session encryption key;</p><p>• Enable AitM detection (see (4));</p><p>• Delay the transmission of the certificate by the server to the browser to *after* the moment that the TLS connection is encrypted - which happens since TLS v1.3.</p><p>Note: the last point even *proves* that the certificate cannot be used for encryption: it is transferred AFTER symmetric endryption starts. See also (4).</p><p>————————<br />(2) People are NEVER E2EE endpoints<br />————————<br />Unfortunately users are incapable of performing the complicated calculation required by encryption. The fact that their browser is one of the endpoints of an E2EE connection, significantly increases user risks (e.g. consider Man-in-the-Browser attacks and techniques like Client-Side Scanning).</p><p>————————<br />(3) Not EVERYTHING is encrypted<br />————————<br />Encryption does not prevent malicious network monitoring. Data such as IP-addresses are sent in the plain, and saving encrypted session data increases the risk that attackers later on manage to break the encryption (for example, if insufficieny secure Diffie-Hellman parameters were used).</p><p>————————<br />(4) https PARTIALLY prevents AitMs/MitMs<br />————————<br />TLS and https (because it's built on TLS) excelently prevent AitM (Attacker-in-the-Middle aka MitM) attacks when *NOT* taking into account the human factor.</p><p>————————<br />(4a) Flawed REAL LIFE AitM detection<br />————————<br />To understand the importance of the ability of TLS to always detect AitM attacks, please consider the following (potentially undetected) AitM attack affecting Nancy and her Mother, who are used to communicate using a chat app (a similar atack may take place using phone calls, but that either requires voice manipulation or some social engineering):</p><p>————<br />Mom (not easily cheated)<br />^<br />| Step 1, AitM to Mom: "Nancy here.<br />| I broke my phone and now I have a<br />| new number. I ran out of money, the<br />| phone was expensive. Can you<br />| please transfer $800 to <bank nr>?"<br />|<br />| Step 2, Mom to 'Nancy': "What is the<br />| password that we agreed upon for<br />| such cases?"<br />|<br />| Step 3, AitM (claiming to be Nancy):<br />| "Ah that's right, I'll have to look<br />| that up, wait a sec."<br />|<br />| The AitM now apps Nancy (see step<br />| 4).<br />v<br />AitM (LOL)<br />^ <br />| Step 4, AitM to Nancy:<br />| "I'm your mom. I broke my phone and<br />| now have a new phone and a new<br />| number. Some time ago we agreed<br />| upon a password to use when the<br />| other one asks for a favor. However,<br />| that password was stored on my<br />| old phone and I don't remember it.<br />| What again was the password that<br />| we agreed upon?<br />| BTW remember: *never* give it<br />| away when an impostor, such as<br />| who supposedly "has a new<br />| phone", asks you to do them a<br />| favor!"<br />|<br />| Step 5, Nancy to 'Mom':<br />| "correct horse battery staple."<br />v<br />Nancy (not easily cheated)<br />————</p><p>I'll leave the next steps to your imagination.</p><p>————————<br />(4b) TLS/https strong AitM detection<br />————————<br />Back to TLS (which https builds upon). A critical detail is that the server uses it's certificate (actually the private key) to digitally sign the public Diffie-Hellman parameters that were exchanged before the session was encrypted. To clarify (in practice the public keys mentioned are huge unpredictable numbers):</p><p>————<br />Server called "example.com"<br />• Certificate: {example.com, pubkey}<br />• privkey (associated with pubkey in cert)<br />----<br />^ <br />| Server side ephemerical pubkey = 3<br />| Encrypted session 1<br />| Client side ephemerical pubkey = 5<br />v<br />AitM<br />^<br />| Server side ephemerical pubkey = 7<br />| Encrypted session 2<br />| Client side ephemerical pubkey = 9<br />v<br />Browser<br />————</p><p>The server signs their "server side ephemerical pubkey" value "3" with its private key associated with the public key in its certificate, and then sends both the certificate and the signed value "3" to the browser.</p><p>The browser compares the signed value "3" with the "server side ephemerical pubkey" value "7" as seen by the browser. Since they differ, the browser knows that an AitM must be present, and shows a certificate error.</p><p>As long as the attacker does not possess a private key + associated certificate *that is trusted by the browser*, TLS-AitM's are impossible in practice (not taking vulnerabilities into account). Another precondition is that the user knows that the domain name shown in the address bar of their browser actually belongs to the organization they think that they're communicating with - which is a HUGE issue - but unrelated to TLS itself.</p><p>Finally, if the user begins by entering https:⁄⁄www.bleepingcomputer.com (I've replaced '//' by '⁄⁄' to prevent Mastodon from hiding them), then there are three possibilities, ordered in decreasing probability:</p><p>a) The browser connects to the *real* bleepingcomputer.com server;</p><p>b) The browser issues a certificate warning or error;</p><p>c) Unlikely: a certificate was mis-issued to impostors, an untrustworthy rootcertificate was added to the certificate store used by the browser, some vulnerability was exploited, bleepingcomputer.com was compromised and redirects the browser to some other site, or the browser was compromised.</p><p>*BONUS POINTS DETAILS*</p><p>————————<br />(5) Identification<br />————————<br />Identification is the proces of determining attributes of an entity (a tangible or untangible "thing"), in order to *recognize* it, based upon having "seen" the entity before, or by relying on attributes described by others. Identification does not always need to be unique (e.g. knowing "it's a banana" usually suffices).</p><p>Identification of a website takes place by looking at the domain name in the browser's addres bar (the domain name is the commonly used identifying attribute of a public web server).</p><p>When using an https connection, additional identifying details of the *owner* of the domain name *may* be present in the server's certificate. However, over the last decade, more often than not, such details are no longer included in server certificates. And even if they are: when using mobile browsers in particular, such additional details can either only be partially visualized (in Chrome, on Android only) or not at all. This significantly limits the ability of internet users to distinguish between real and impersonated websites.</p><p>————————<br />(6) Authentication when using TLS/https<br />————————<br />Authentication is the proces of determining whether identifying information and an entity "match" ("belong together"), e.g. is the person who he/she claims to be. The reliability of authentication may vary *a lot*.</p><p>In contrast to identification, authentication is often used to prove the identity of one specific entity (OTOH, sometimes multiple persons share one user-ID and password to log in to one acount).</p><p>W.r.t. https: the entity is the website, and usually a public domain name is used to identify such an entity.</p><p>Note: a webserver may host multiple websites - distinguished by their domain names (which is why I refer to websites).</p><p>Technical authentication of a website takes place as follows:</p><p>• The server proves possession of a private key uniquely associated with the public key in the server certificate;</p><p>• The browser verifies the validity of the certificate (sent to the browser by the server) and confirms that the certificate is valid for the domain name shown in the browser's address bar. The browser will issue a certificate warning or error if anything fails.</p><p>————————<br />(7) Impersonation of websites (phishing)<br />————————<br />It is an exception, but sometimes attackers manage to obtain certificates for domain names that are not theirs. For example, on July 23 (2024) Let's Encrypt issued 34 certificates to subdomains of dydx.exchange (and that domain name itself). Among the interesting aspects of this certificate mis-issuance incident is the fact that Let's Encrypt revoked only 27 certificates (approx. 6.5 hours after issuing them).</p><p>Note: for more info regarding the DNS attack that lead to this certificate mis-issuance incident, see <a href=\"https://www.bleepingcomputer.com/news/security/defi-exchange-dydx-v3-website-hacked-in-dns-hijack-attack/\" target=\"_blank\" rel=\"nofollow noopener\" translate=\"no\"><span class=\"invisible\">https://www.</span><span class=\"ellipsis\">bleepingcomputer.com/news/secu</span><span class=\"invisible\">rity/defi-exchange-dydx-v3-website-hacked-in-dns-hijack-attack/</span></a> (that article does not yet mention the certificates mis-issuance incident).</p><p>See my next toot for the last part of this series of three.</p><p>[1] <a href=\"https://en.wikipedia.org/wiki/Forward_secrecy\" target=\"_blank\" rel=\"nofollow noopener\" translate=\"no\"><span class=\"invisible\">https://</span><span class=\"ellipsis\">en.wikipedia.org/wiki/Forward_</span><span class=\"invisible\">secrecy</span></a></p><p>[2] <a href=\"https://en.wikipedia.org/wiki/Diffie%E2%80%93Hellman_key_exchange\" target=\"_blank\" rel=\"nofollow noopener\" translate=\"no\"><span class=\"invisible\">https://</span><span class=\"ellipsis\">en.wikipedia.org/wiki/Diffie%E</span><span class=\"invisible\">2%80%93Hellman_key_exchange</span></a></p><p><span class=\"h-card\" translate=\"no\"><a href=\"https://beta.mstdn.cf/users/billtoulas\" class=\"u-url mention\">@<span>billtoulas</span></a></span> <br /><span class=\"h-card\" translate=\"no\"><a href=\"https://infosec.exchange/@BleepingComputer\" class=\"u-url mention\">@<span>BleepingComputer</span></a></span> </p><p><a href=\"https://infosec.exchange/tags/Certificates\" class=\"mention hashtag\" rel=\"tag\">#<span>Certificates</span></a> <a href=\"https://infosec.exchange/tags/https\" class=\"mention hashtag\" rel=\"tag\">#<span>https</span></a> <a href=\"https://infosec.exchange/tags/TLS\" class=\"mention hashtag\" rel=\"tag\">#<span>TLS</span></a> <a href=\"https://infosec.exchange/tags/Encryption\" class=\"mention hashtag\" rel=\"tag\">#<span>Encryption</span></a> <a href=\"https://infosec.exchange/tags/Signing\" class=\"mention hashtag\" rel=\"tag\">#<span>Signing</span></a> <a href=\"https://infosec.exchange/tags/DV\" class=\"mention hashtag\" rel=\"tag\">#<span>DV</span></a> <a href=\"https://infosec.exchange/tags/DomainValidation\" class=\"mention hashtag\" rel=\"tag\">#<span>DomainValidation</span></a> <a href=\"https://infosec.exchange/tags/AitM\" class=\"mention hashtag\" rel=\"tag\">#<span>AitM</span></a> <a href=\"https://infosec.exchange/tags/MitM\" class=\"mention hashtag\" rel=\"tag\">#<span>MitM</span></a> <a href=\"https://infosec.exchange/tags/Identification\" class=\"mention hashtag\" rel=\"tag\">#<span>Identification</span></a> <a href=\"https://infosec.exchange/tags/Authentication\" class=\"mention hashtag\" rel=\"tag\">#<span>Authentication</span></a> <a href=\"https://infosec.exchange/tags/Impersonation\" class=\"mention hashtag\" rel=\"tag\">#<span>Impersonation</span></a> <a href=\"https://infosec.exchange/tags/OV\" class=\"mention hashtag\" rel=\"tag\">#<span>OV</span></a> <a href=\"https://infosec.exchange/tags/EV\" class=\"mention hashtag\" rel=\"tag\">#<span>EV</span></a> <a href=\"https://infosec.exchange/tags/QWAC\" class=\"mention hashtag\" rel=\"tag\">#<span>QWAC</span></a> <a href=\"https://infosec.exchange/tags/LE\" class=\"mention hashtag\" rel=\"tag\">#<span>LE</span></a> <a href=\"https://infosec.exchange/tags/LetsEncrypt\" class=\"mention hashtag\" rel=\"tag\">#<span>LetsEncrypt</span></a> <a href=\"https://infosec.exchange/tags/MisIssuance\" class=\"mention hashtag\" rel=\"tag\">#<span>MisIssuance</span></a> <a href=\"https://infosec.exchange/tags/Revocation\" class=\"mention hashtag\" rel=\"tag\">#<span>Revocation</span></a> <a href=\"https://infosec.exchange/tags/Revoked\" class=\"mention hashtag\" rel=\"tag\">#<span>Revoked</span></a> <a href=\"https://infosec.exchange/tags/OCSP\" class=\"mention hashtag\" rel=\"tag\">#<span>OCSP</span></a> <a href=\"https://infosec.exchange/tags/OCSPStapling\" class=\"mention hashtag\" rel=\"tag\">#<span>OCSPStapling</span></a> <a href=\"https://infosec.exchange/tags/CRL\" class=\"mention hashtag\" rel=\"tag\">#<span>CRL</span></a> <a href=\"https://infosec.exchange/tags/CertificateMisIssuance\" class=\"mention hashtag\" rel=\"tag\">#<span>CertificateMisIssuance</span></a> <a href=\"https://infosec.exchange/tags/DNS\" class=\"mention hashtag\" rel=\"tag\">#<span>DNS</span></a> <a href=\"https://infosec.exchange/tags/DNSHijack\" class=\"mention hashtag\" rel=\"tag\">#<span>DNSHijack</span></a> <a href=\"https://infosec.exchange/tags/BGP\" class=\"mention hashtag\" rel=\"tag\">#<span>BGP</span></a> <a href=\"https://infosec.exchange/tags/BGPHijack\" class=\"mention hashtag\" rel=\"tag\">#<span>BGPHijack</span></a> <a href=\"https://infosec.exchange/tags/Trust\" class=\"mention hashtag\" rel=\"tag\">#<span>Trust</span></a> <a href=\"https://infosec.exchange/tags/Reliability\" class=\"mention hashtag\" rel=\"tag\">#<span>Reliability</span></a></p>",
"contentMap": {
"en": "<p>Detailed explanation of what I wrote in <a href=\"https://infosec.exchange/@ErikvanStraten/112882437562055760\" target=\"_blank\" rel=\"nofollow noopener\" translate=\"no\"><span class=\"invisible\">https://</span><span class=\"ellipsis\">infosec.exchange/@ErikvanStrat</span><span class=\"invisible\">en/112882437562055760</span></a></p><p>————————<br />(1) Server certs NOT used for encryption<br />————————<br />Server certificates are not used for emcryption when using "forward secrecy" [1] - a common practice for a decade or so.</p><p>TLS sessions are encrypted using a randomly generated symmetric (e.g. AES) encryption key, for example generated by the browser.</p><p>The chicken-and-egg problem then is how to securily transfer that session key to the server over an unencrypted connection.</p><p>Before TLS v1.3, the server would automatically send it's certificate to the browser soon after the (still unencrypted) TCP/IP connection was established.</p><p>Long ago the browser would then generate the symmetric encryption key, and use the public key from the server certificate to encrypt the session key. As only the possessor of the associated private key can decrypt the result, the encrypted symmetric key could be securily transmitted over the (still unencrypted) TCP/IP connection.</p><p>Problem: if attackers or three-letter agencies capture and save encrypted session data (partially encrypted network packets), and later steal or demand a copy of the server's private key, then they can decrypt the (asymmetrically) encrypted session key, and thereafter, decrypt the entire session.</p><p>Solution (simplified), using forward secrecy [1]: for each session, the server and the browser generate an ephemerical (intended for temporary use) asymmetric keypair and exchange their public keys.</p><p>Without going into too many details [2], those ephemerical keys are used to:</p><p>• Mutually agree upon a symmetric session encryption key;</p><p>• Enable AitM detection (see (4));</p><p>• Delay the transmission of the certificate by the server to the browser to *after* the moment that the TLS connection is encrypted - which happens since TLS v1.3.</p><p>Note: the last point even *proves* that the certificate cannot be used for encryption: it is transferred AFTER symmetric endryption starts. See also (4).</p><p>————————<br />(2) People are NEVER E2EE endpoints<br />————————<br />Unfortunately users are incapable of performing the complicated calculation required by encryption. The fact that their browser is one of the endpoints of an E2EE connection, significantly increases user risks (e.g. consider Man-in-the-Browser attacks and techniques like Client-Side Scanning).</p><p>————————<br />(3) Not EVERYTHING is encrypted<br />————————<br />Encryption does not prevent malicious network monitoring. Data such as IP-addresses are sent in the plain, and saving encrypted session data increases the risk that attackers later on manage to break the encryption (for example, if insufficieny secure Diffie-Hellman parameters were used).</p><p>————————<br />(4) https PARTIALLY prevents AitMs/MitMs<br />————————<br />TLS and https (because it's built on TLS) excelently prevent AitM (Attacker-in-the-Middle aka MitM) attacks when *NOT* taking into account the human factor.</p><p>————————<br />(4a) Flawed REAL LIFE AitM detection<br />————————<br />To understand the importance of the ability of TLS to always detect AitM attacks, please consider the following (potentially undetected) AitM attack affecting Nancy and her Mother, who are used to communicate using a chat app (a similar atack may take place using phone calls, but that either requires voice manipulation or some social engineering):</p><p>————<br />Mom (not easily cheated)<br />^<br />| Step 1, AitM to Mom: "Nancy here.<br />| I broke my phone and now I have a<br />| new number. I ran out of money, the<br />| phone was expensive. Can you<br />| please transfer $800 to <bank nr>?"<br />|<br />| Step 2, Mom to 'Nancy': "What is the<br />| password that we agreed upon for<br />| such cases?"<br />|<br />| Step 3, AitM (claiming to be Nancy):<br />| "Ah that's right, I'll have to look<br />| that up, wait a sec."<br />|<br />| The AitM now apps Nancy (see step<br />| 4).<br />v<br />AitM (LOL)<br />^ <br />| Step 4, AitM to Nancy:<br />| "I'm your mom. I broke my phone and<br />| now have a new phone and a new<br />| number. Some time ago we agreed<br />| upon a password to use when the<br />| other one asks for a favor. However,<br />| that password was stored on my<br />| old phone and I don't remember it.<br />| What again was the password that<br />| we agreed upon?<br />| BTW remember: *never* give it<br />| away when an impostor, such as<br />| who supposedly "has a new<br />| phone", asks you to do them a<br />| favor!"<br />|<br />| Step 5, Nancy to 'Mom':<br />| "correct horse battery staple."<br />v<br />Nancy (not easily cheated)<br />————</p><p>I'll leave the next steps to your imagination.</p><p>————————<br />(4b) TLS/https strong AitM detection<br />————————<br />Back to TLS (which https builds upon). A critical detail is that the server uses it's certificate (actually the private key) to digitally sign the public Diffie-Hellman parameters that were exchanged before the session was encrypted. To clarify (in practice the public keys mentioned are huge unpredictable numbers):</p><p>————<br />Server called "example.com"<br />• Certificate: {example.com, pubkey}<br />• privkey (associated with pubkey in cert)<br />----<br />^ <br />| Server side ephemerical pubkey = 3<br />| Encrypted session 1<br />| Client side ephemerical pubkey = 5<br />v<br />AitM<br />^<br />| Server side ephemerical pubkey = 7<br />| Encrypted session 2<br />| Client side ephemerical pubkey = 9<br />v<br />Browser<br />————</p><p>The server signs their "server side ephemerical pubkey" value "3" with its private key associated with the public key in its certificate, and then sends both the certificate and the signed value "3" to the browser.</p><p>The browser compares the signed value "3" with the "server side ephemerical pubkey" value "7" as seen by the browser. Since they differ, the browser knows that an AitM must be present, and shows a certificate error.</p><p>As long as the attacker does not possess a private key + associated certificate *that is trusted by the browser*, TLS-AitM's are impossible in practice (not taking vulnerabilities into account). Another precondition is that the user knows that the domain name shown in the address bar of their browser actually belongs to the organization they think that they're communicating with - which is a HUGE issue - but unrelated to TLS itself.</p><p>Finally, if the user begins by entering https:⁄⁄www.bleepingcomputer.com (I've replaced '//' by '⁄⁄' to prevent Mastodon from hiding them), then there are three possibilities, ordered in decreasing probability:</p><p>a) The browser connects to the *real* bleepingcomputer.com server;</p><p>b) The browser issues a certificate warning or error;</p><p>c) Unlikely: a certificate was mis-issued to impostors, an untrustworthy rootcertificate was added to the certificate store used by the browser, some vulnerability was exploited, bleepingcomputer.com was compromised and redirects the browser to some other site, or the browser was compromised.</p><p>*BONUS POINTS DETAILS*</p><p>————————<br />(5) Identification<br />————————<br />Identification is the proces of determining attributes of an entity (a tangible or untangible "thing"), in order to *recognize* it, based upon having "seen" the entity before, or by relying on attributes described by others. Identification does not always need to be unique (e.g. knowing "it's a banana" usually suffices).</p><p>Identification of a website takes place by looking at the domain name in the browser's addres bar (the domain name is the commonly used identifying attribute of a public web server).</p><p>When using an https connection, additional identifying details of the *owner* of the domain name *may* be present in the server's certificate. However, over the last decade, more often than not, such details are no longer included in server certificates. And even if they are: when using mobile browsers in particular, such additional details can either only be partially visualized (in Chrome, on Android only) or not at all. This significantly limits the ability of internet users to distinguish between real and impersonated websites.</p><p>————————<br />(6) Authentication when using TLS/https<br />————————<br />Authentication is the proces of determining whether identifying information and an entity "match" ("belong together"), e.g. is the person who he/she claims to be. The reliability of authentication may vary *a lot*.</p><p>In contrast to identification, authentication is often used to prove the identity of one specific entity (OTOH, sometimes multiple persons share one user-ID and password to log in to one acount).</p><p>W.r.t. https: the entity is the website, and usually a public domain name is used to identify such an entity.</p><p>Note: a webserver may host multiple websites - distinguished by their domain names (which is why I refer to websites).</p><p>Technical authentication of a website takes place as follows:</p><p>• The server proves possession of a private key uniquely associated with the public key in the server certificate;</p><p>• The browser verifies the validity of the certificate (sent to the browser by the server) and confirms that the certificate is valid for the domain name shown in the browser's address bar. The browser will issue a certificate warning or error if anything fails.</p><p>————————<br />(7) Impersonation of websites (phishing)<br />————————<br />It is an exception, but sometimes attackers manage to obtain certificates for domain names that are not theirs. For example, on July 23 (2024) Let's Encrypt issued 34 certificates to subdomains of dydx.exchange (and that domain name itself). Among the interesting aspects of this certificate mis-issuance incident is the fact that Let's Encrypt revoked only 27 certificates (approx. 6.5 hours after issuing them).</p><p>Note: for more info regarding the DNS attack that lead to this certificate mis-issuance incident, see <a href=\"https://www.bleepingcomputer.com/news/security/defi-exchange-dydx-v3-website-hacked-in-dns-hijack-attack/\" target=\"_blank\" rel=\"nofollow noopener\" translate=\"no\"><span class=\"invisible\">https://www.</span><span class=\"ellipsis\">bleepingcomputer.com/news/secu</span><span class=\"invisible\">rity/defi-exchange-dydx-v3-website-hacked-in-dns-hijack-attack/</span></a> (that article does not yet mention the certificates mis-issuance incident).</p><p>See my next toot for the last part of this series of three.</p><p>[1] <a href=\"https://en.wikipedia.org/wiki/Forward_secrecy\" target=\"_blank\" rel=\"nofollow noopener\" translate=\"no\"><span class=\"invisible\">https://</span><span class=\"ellipsis\">en.wikipedia.org/wiki/Forward_</span><span class=\"invisible\">secrecy</span></a></p><p>[2] <a href=\"https://en.wikipedia.org/wiki/Diffie%E2%80%93Hellman_key_exchange\" target=\"_blank\" rel=\"nofollow noopener\" translate=\"no\"><span class=\"invisible\">https://</span><span class=\"ellipsis\">en.wikipedia.org/wiki/Diffie%E</span><span class=\"invisible\">2%80%93Hellman_key_exchange</span></a></p><p><span class=\"h-card\" translate=\"no\"><a href=\"https://beta.mstdn.cf/users/billtoulas\" class=\"u-url mention\">@<span>billtoulas</span></a></span> <br /><span class=\"h-card\" translate=\"no\"><a href=\"https://infosec.exchange/@BleepingComputer\" class=\"u-url mention\">@<span>BleepingComputer</span></a></span> </p><p><a href=\"https://infosec.exchange/tags/Certificates\" class=\"mention hashtag\" rel=\"tag\">#<span>Certificates</span></a> <a href=\"https://infosec.exchange/tags/https\" class=\"mention hashtag\" rel=\"tag\">#<span>https</span></a> <a href=\"https://infosec.exchange/tags/TLS\" class=\"mention hashtag\" rel=\"tag\">#<span>TLS</span></a> <a href=\"https://infosec.exchange/tags/Encryption\" class=\"mention hashtag\" rel=\"tag\">#<span>Encryption</span></a> <a href=\"https://infosec.exchange/tags/Signing\" class=\"mention hashtag\" rel=\"tag\">#<span>Signing</span></a> <a href=\"https://infosec.exchange/tags/DV\" class=\"mention hashtag\" rel=\"tag\">#<span>DV</span></a> <a href=\"https://infosec.exchange/tags/DomainValidation\" class=\"mention hashtag\" rel=\"tag\">#<span>DomainValidation</span></a> <a href=\"https://infosec.exchange/tags/AitM\" class=\"mention hashtag\" rel=\"tag\">#<span>AitM</span></a> <a href=\"https://infosec.exchange/tags/MitM\" class=\"mention hashtag\" rel=\"tag\">#<span>MitM</span></a> <a href=\"https://infosec.exchange/tags/Identification\" class=\"mention hashtag\" rel=\"tag\">#<span>Identification</span></a> <a href=\"https://infosec.exchange/tags/Authentication\" class=\"mention hashtag\" rel=\"tag\">#<span>Authentication</span></a> <a href=\"https://infosec.exchange/tags/Impersonation\" class=\"mention hashtag\" rel=\"tag\">#<span>Impersonation</span></a> <a href=\"https://infosec.exchange/tags/OV\" class=\"mention hashtag\" rel=\"tag\">#<span>OV</span></a> <a href=\"https://infosec.exchange/tags/EV\" class=\"mention hashtag\" rel=\"tag\">#<span>EV</span></a> <a href=\"https://infosec.exchange/tags/QWAC\" class=\"mention hashtag\" rel=\"tag\">#<span>QWAC</span></a> <a href=\"https://infosec.exchange/tags/LE\" class=\"mention hashtag\" rel=\"tag\">#<span>LE</span></a> <a href=\"https://infosec.exchange/tags/LetsEncrypt\" class=\"mention hashtag\" rel=\"tag\">#<span>LetsEncrypt</span></a> <a href=\"https://infosec.exchange/tags/MisIssuance\" class=\"mention hashtag\" rel=\"tag\">#<span>MisIssuance</span></a> <a href=\"https://infosec.exchange/tags/Revocation\" class=\"mention hashtag\" rel=\"tag\">#<span>Revocation</span></a> <a href=\"https://infosec.exchange/tags/Revoked\" class=\"mention hashtag\" rel=\"tag\">#<span>Revoked</span></a> <a href=\"https://infosec.exchange/tags/OCSP\" class=\"mention hashtag\" rel=\"tag\">#<span>OCSP</span></a> <a href=\"https://infosec.exchange/tags/OCSPStapling\" class=\"mention hashtag\" rel=\"tag\">#<span>OCSPStapling</span></a> <a href=\"https://infosec.exchange/tags/CRL\" class=\"mention hashtag\" rel=\"tag\">#<span>CRL</span></a> <a href=\"https://infosec.exchange/tags/CertificateMisIssuance\" class=\"mention hashtag\" rel=\"tag\">#<span>CertificateMisIssuance</span></a> <a href=\"https://infosec.exchange/tags/DNS\" class=\"mention hashtag\" rel=\"tag\">#<span>DNS</span></a> <a href=\"https://infosec.exchange/tags/DNSHijack\" class=\"mention hashtag\" rel=\"tag\">#<span>DNSHijack</span></a> <a href=\"https://infosec.exchange/tags/BGP\" class=\"mention hashtag\" rel=\"tag\">#<span>BGP</span></a> <a href=\"https://infosec.exchange/tags/BGPHijack\" class=\"mention hashtag\" rel=\"tag\">#<span>BGPHijack</span></a> <a href=\"https://infosec.exchange/tags/Trust\" class=\"mention hashtag\" rel=\"tag\">#<span>Trust</span></a> <a href=\"https://infosec.exchange/tags/Reliability\" class=\"mention hashtag\" rel=\"tag\">#<span>Reliability</span></a></p>"
},
"updated": "2024-07-31T18:22:25Z",
"attachment": [],
"tag": [
{
"type": "Mention",
"href": "https://beta.mstdn.cf/users/billtoulas",
"name": "@billtoulas@beta.mstdn.cf"
},
{
"type": "Mention",
"href": "https://infosec.exchange/users/BleepingComputer",
"name": "@BleepingComputer"
},
{
"type": "Hashtag",
"href": "https://infosec.exchange/tags/certificates",
"name": "#certificates"
},
{
"type": "Hashtag",
"href": "https://infosec.exchange/tags/https",
"name": "#https"
},
{
"type": "Hashtag",
"href": "https://infosec.exchange/tags/tls",
"name": "#tls"
},
{
"type": "Hashtag",
"href": "https://infosec.exchange/tags/encryption",
"name": "#encryption"
},
{
"type": "Hashtag",
"href": "https://infosec.exchange/tags/signing",
"name": "#signing"
},
{
"type": "Hashtag",
"href": "https://infosec.exchange/tags/dv",
"name": "#dv"
},
{
"type": "Hashtag",
"href": "https://infosec.exchange/tags/domainvalidation",
"name": "#domainvalidation"
},
{
"type": "Hashtag",
"href": "https://infosec.exchange/tags/AiTM",
"name": "#AiTM"
},
{
"type": "Hashtag",
"href": "https://infosec.exchange/tags/mitm",
"name": "#mitm"
},
{
"type": "Hashtag",
"href": "https://infosec.exchange/tags/identification",
"name": "#identification"
},
{
"type": "Hashtag",
"href": "https://infosec.exchange/tags/authentication",
"name": "#authentication"
},
{
"type": "Hashtag",
"href": "https://infosec.exchange/tags/impersonation",
"name": "#impersonation"
},
{
"type": "Hashtag",
"href": "https://infosec.exchange/tags/ov",
"name": "#ov"
},
{
"type": "Hashtag",
"href": "https://infosec.exchange/tags/ev",
"name": "#ev"
},
{
"type": "Hashtag",
"href": "https://infosec.exchange/tags/QWAC",
"name": "#QWAC"
},
{
"type": "Hashtag",
"href": "https://infosec.exchange/tags/le",
"name": "#le"
},
{
"type": "Hashtag",
"href": "https://infosec.exchange/tags/letsencrypt",
"name": "#letsencrypt"
},
{
"type": "Hashtag",
"href": "https://infosec.exchange/tags/misissuance",
"name": "#misissuance"
},
{
"type": "Hashtag",
"href": "https://infosec.exchange/tags/revocation",
"name": "#revocation"
},
{
"type": "Hashtag",
"href": "https://infosec.exchange/tags/revoked",
"name": "#revoked"
},
{
"type": "Hashtag",
"href": "https://infosec.exchange/tags/ocsp",
"name": "#ocsp"
},
{
"type": "Hashtag",
"href": "https://infosec.exchange/tags/ocspstapling",
"name": "#ocspstapling"
},
{
"type": "Hashtag",
"href": "https://infosec.exchange/tags/crl",
"name": "#crl"
},
{
"type": "Hashtag",
"href": "https://infosec.exchange/tags/certificatemisissuance",
"name": "#certificatemisissuance"
},
{
"type": "Hashtag",
"href": "https://infosec.exchange/tags/dns",
"name": "#dns"
},
{
"type": "Hashtag",
"href": "https://infosec.exchange/tags/dnshijack",
"name": "#dnshijack"
},
{
"type": "Hashtag",
"href": "https://infosec.exchange/tags/bgp",
"name": "#bgp"
},
{
"type": "Hashtag",
"href": "https://infosec.exchange/tags/bgphijack",
"name": "#bgphijack"
},
{
"type": "Hashtag",
"href": "https://infosec.exchange/tags/trust",
"name": "#trust"
},
{
"type": "Hashtag",
"href": "https://infosec.exchange/tags/reliability",
"name": "#reliability"
}
],
"replies": {
"id": "https://infosec.exchange/users/ErikvanStraten/statuses/112882463034102550/replies",
"type": "Collection",
"first": {
"type": "CollectionPage",
"next": "https://infosec.exchange/users/ErikvanStraten/statuses/112882463034102550/replies?min_id=112882465872869504&page=true",
"partOf": "https://infosec.exchange/users/ErikvanStraten/statuses/112882463034102550/replies",
"items": [
"https://infosec.exchange/users/ErikvanStraten/statuses/112882465872869504"
]
}
},
"likes": {
"id": "https://infosec.exchange/users/ErikvanStraten/statuses/112882463034102550/likes",
"type": "Collection",
"totalItems": 2
},
"shares": {
"id": "https://infosec.exchange/users/ErikvanStraten/statuses/112882463034102550/shares",
"type": "Collection",
"totalItems": 0
}
}
]
}
}