mirsal/capsul-flask
0
0
Fork 0
forked from 3wordchant/capsul-flask
Code Issues Pull Requests Projects Releases Wiki Activity

mor grammer fixs

Browse Source
This commit is contained in:
forest 2021-01-31 00:57:33 -06:00
parent ebaf348dd3
commit 7a904114c3
1 changed files with 8 additions and 7 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

15
capsulflask/templates/about-ssh.html
View File

@ -109,8 +109,8 @@
steal tons of credit card numbers and passwords.
</p>
<p>
In order to enable this, a new sub-protocol called <a href="https://en.wikipedia.org/wiki/X.509">X.509</a> was created.
X.509 is a standard related to the data format of certificates and keys (public keys and private keys), but it also defines
In order to enable this, a new standard called <a href="https://en.wikipedia.org/wiki/X.509">X.509</a> was created.
X.509 dictates the data format of certificates and keys (public keys and private keys), and it also defines
a simple and easy way to determine whether a given certificate (public key) is authentic.
X.509 introduced the concept of a Certificate Authority, or CA.
These CAs were supposed to be bank-like public institutions of power which everyone could trust.
@ -143,7 +143,7 @@
<li>
Does the certificate contain a valid CA signature?
(can the signature on the certificate be decrypted by one of the CA Certificates included with the operating system?)
If not, display a <a href="https://untrusted-root.badssl.com/">UNKNOWN_ISSUER error</a>.
If not, display an <a href="https://untrusted-root.badssl.com/">UNKNOWN_ISSUER error</a>.
</li>
</ul>
</li>
@ -178,7 +178,7 @@
allow themselves to be subjugated by so-called "Certificate Authorities".
So, what are they doing instead? Where is SSH at? Well, back when it was created, computer security was easy —
a very minimal defense was enough to deter attackers.
In order to help prevent these MITM attacks, instead of something like X.509, SSH uses a policy called
In order to help prevent these MITM attacks, instead of something like X.509, SSH employs a policy called
<a href="https://en.wikipedia.org/wiki/Trust_on_first_use">Trust On First Use (TOFU)</a>.
</p>
@ -207,7 +207,8 @@
Here, the SSH client is displaying the fingerprint (<a href="https://en.wikipedia.org/wiki/SHA-2">SHA256 hash</a>)
of the public key provided by the server at <span class="code">fooserver.com</span>.
Back in the day, when SSH was created, servers lived for months to years, not minutes, and they were installed by hand.
So it would have been perfectly reasonable to call the person installing the server
So it would have been perfectly reasonable to call the person installing the server on thier
<a href="https://nokiamuseum.info/nokia-909/">Nokia 909</a>
and ask them to log into it & read off the host key fingerprint over the phone.
After verifing that the fingerprints match in the phone call, the user would type <span class="code">yes</span>
to continue.
@ -255,8 +256,8 @@ Host key verification failed.
If you type <span class="code">yes</span> here without checking the server's host key somehow, you could add an attackers public key to the trusted
list in your <span class="code">~/.ssh/known_hosts</span> file; if you type <span class="code">yes</span> blindly, you are
<b>completely disabling all security of the SSH connection</b>.
It can be fully man-in-the-middle attacked & you are vulnerable to spying, command injection, result-falsification,
the whole nine yards.
It can be fully man-in-the-middle attacked & you are
vulnerable to surveillance, command injection, even emulation/falsification of the entire stream.
</p>
<p>