forked from 3wordchant/capsul-flask
		
	dont put lists inside <p> tags
This commit is contained in:
		| @ -27,6 +27,7 @@ | ||||
|  | ||||
| <p> | ||||
|   Computers can generate <b>"key pairs"</b> which consist of a public key and a private key. Given a <b>public key pair A</b>: | ||||
| </p> | ||||
|   <ol> | ||||
|     <li> | ||||
|       A computer which has access to <b>public key A</b> can encrypt data,  | ||||
| @ -38,15 +39,19 @@ | ||||
|       thus <b>PROVING</b> the message must have come from someone who posesses <b>private key A</b> | ||||
|     </li> | ||||
|   </ol> | ||||
| <p> | ||||
|   Key exchange is a process in which two computers, Computer A and Computer B (often referred to as Alice and Bob) | ||||
|   both create key pairs, so you have <b>key pair A</b> and <b>key pair B</b>, for a total of 4 keys: | ||||
| </p> | ||||
|   <ol> | ||||
|     <li><b>public key A</b></li> | ||||
|     <li><b>private key A</b></li> | ||||
|     <li><b>public key B</b></li> | ||||
|     <li><b>private key B</b></li> | ||||
|   </ol> | ||||
|   <p> | ||||
|   In simplified terms, during a key exchange,  | ||||
| </p> | ||||
|   <ol> | ||||
|     <li><b>computer A</b> sends <b>computer B</b> its public key</li> | ||||
|     <li><b>computer B</b> sends <b>computer A</b> its public key</li> | ||||
| @ -55,6 +60,7 @@ | ||||
|     <li><b>computer B</b> sends <b>computer A</b>  | ||||
|       a message which is encrypted with <b>computer A</b>'s public key</li> | ||||
|   </ol> | ||||
| <p> | ||||
|   The way this process is carried out allows A and B to communicate with each-other securely, which is great, <br/><br/> | ||||
|  | ||||
|   <b><u>HOWEVER, there is a catch!!</u></b> | ||||
| @ -115,7 +121,7 @@ | ||||
|   Critically, issue date, expiration date, and the domain name of the web server, like foo.example.com, would have to be included  | ||||
|   in the x.509 certiciate along with the public key.  | ||||
|   This way, when the user types https://foo.example.com into thier web browser: | ||||
|  | ||||
| </p> | ||||
|   <ol> | ||||
|     <li>The web browser sends a TLS ClientHello request to the server</li> | ||||
|     <li> | ||||
| @ -143,7 +149,6 @@ | ||||
|     </li> | ||||
|     <li>Assuming all the checks pass, the web browser trusts the certificate and connects</li> | ||||
|   </ol> | ||||
| </p> | ||||
| <p> | ||||
|   This system enabled the internet to grow and flourish: | ||||
|   purchasing from a CA was the only way to get a valid X.509 certificate for a website,  | ||||
| @ -155,6 +160,7 @@ | ||||
| </p> | ||||
| <p> | ||||
|   The TLS+X.509 Certificate Authority works well for HTTP and other application protocols, because  | ||||
| </p> | ||||
|   <ul> | ||||
|     <li>Most internet users don't have the patience to manually verify the authenticity of digital certificates.</li> | ||||
|     <li>Most internet users don't understand or care how it works; they just want to connect right now.</li> | ||||
| @ -163,7 +169,6 @@ | ||||
|     <li>The centralization & problematic power dynamic which CAs represent  | ||||
|       is easily swept under the rug, if it doesn't directly or noticably impact the average person, who cares?</li> | ||||
|   </ul> | ||||
| </p> | ||||
|  | ||||
| <p> | ||||
|   However, this would never fly with SSH. You have to understand, SSH does not come from Microsoft, it does not come from Apple,  | ||||
|  | ||||
		Reference in New Issue
	
	Block a user