So remember, HTTPS is really just HTTP using SSL. SSL and the latest release is TLS, Transport Layer Security. SSL slash TLS can be used for any TCP based application, not just for HTTP. You can use it for email. You can create your own application that will make use of this. So it's for any transport protocol or any application based upon TCP as the transport protocol. But we're using as an example HTTP because that's what we commonly see. We said, and we haven't gone through the details yet, but we have said that really there's a record protocol that does the encryption of data and authentication of data using MAC. So everything that we send, once we've set up a secure connection, we encrypt and attach a MAC for authentication, and that is part of the record protocol. But before we do that, we must exchange keys and agree upon algorithms to use, and that's part of the handshake protocol. Alerts when things go wrong, change cypher spec is just to say, let's change from the path set of keys and let's use the new set because the approach is to exchange a secret using public key cryptography and then encrypt our data using symmetric key cryptography. So we started going through an example from a packet capture from a web browser to a server, and we'll try and finish that today. What we got to is that first there's the normal TCP connection set up. That's the same as normal HTTP, SIN, SINAC, ACK. And then before we send the request, the HTTP get request from browser to server, we actually need to establish a secure connection, the SSL connection. And we started seeing some of the messages involved there. First, the browser sends a hello message to the server, indicating several things, but we noticed that it included some random bytes, and we'll see those random bytes used later as a sort of nonce value, and also a list of preferred sets of cyphers. So there are different sets of cyphers that we are going to use, and we said that in the response eventually that the set of cyphers chosen in this specific example was Diffie-Hellman ephemeral, which is a Diffie-Hellman algorithm used to exchange a temporary secret. Diffie-Hellman's used for secret key exchange, and that's what we use it for here, but we only use that secret for a short time. It's not for a long-term secret. Now the problem with Diffie-Hellman is that a man in the middle attack can occur, so we need to know, say from the browser's perspective, when it receives the Diffie-Hellman parameters, it needs to know it is from the server. It's not something pretending to be the server. And we use RSA authentication there. So in addition to Diffie-Hellman, the server will send a certificate to the browser, and in fact that private key of the server will be used to sign the Diffie-Hellman parameters. So when the Diffie-Hellman parameters are sent by the server to the browser, they are signed by the server. And if they are signed by the server, we need the public key of the server to verify. And the public key of the server is contained in the certificate that it receives, but we must verify the certificate. And we'll see that the certificate we received is signed by an authority. So assuming the browser trusts the authority, it can verify the public key of the server, and therefore it can verify the Diffie-Hellman parameters it receives because they are signed by the server. So one purpose of this combination of two forms of public key cryptography, Diffie-Hellman to exchange a secret, RSA used to verify that those parameters in that exchange are from the server. Once we exchange a secret, when we want to send data between client and server, browser and server, we encrypt using symmetric key encryption. In this case, it will be AES128 using CBC as the mode of operation. So that's the data encryption. Also, all the data we send, we apply a MAC, a message authentication code. What we do is we calculate based upon that data or that fragment of data. We calculated a MAC value using some secret key, and it gives us some tag or some code that we attach. And it allows the receiver to verify that the fragment it receives has not been modified. So that's message integrity. And in this example, the algorithm's chosen, it's always using HMAC, which is a general algorithm to turn a hash function into a MAC function, and the specific hash function used is SHA in this case. So those parameters were exchanged in the hollow messages. Actually, first, the browser sent its list of preferred set of algorithms, and when the server responded with a hello, it sent back the selected set, the ones we saw on the previous picture. And also some random bytes, some different random bytes from the server. The next message from the server contains its RSA certificate. So it contains the public key of the server, matching the domain name we accessed and signed by some authority. And the last message we got to, there are more to come, is a key exchange, a server key exchange message, and it includes the Diffie-Hellman parameters. And if you remember back to Diffie-Hellman, the algorithm, remember there was some public values, alpha, q. Both sides need to know that. The server chooses the alpha and q and sends it to the browser. The server calculates its value of y. Diffie-Hellman was we choose a private x, then we calculate y as alpha to the power of x mod q. So in this key exchange message, the server tells the browser its value of alpha, q, and y, ys there. And when the browser receives it, to check that this is not a man in the middle attack, it's not someone pretending, sending these fake values, that data is all signed with the private key of the server, the RSA private key. So we use the public key of the server to verify that data is correct. So let's see what happens next. Before we do so, any questions on what's happened so far? Today we hope to finish this exchange and we're seeing multiple algorithms being used in practice in this exchange. We got to the server key exchange. Note that some of the SSL handshake messages are sent inside the one packet. So it's possible that you can, in this one for example, from server to browser, it was one packet sent across the network, one TCP packet, but it contained two handshake messages, the low message and the certificate. So that's possible, depending upon the size. And the key exchange contained the key exchange packet. If we look in there, it doesn't show us because it's all signed, but it's 532 bytes. That is the values of the Diffie-Hellman alpha, q, ys, all signed with the private key of the server. But this packet also contains another handshake message. It's server hello done. So the server's done at this point. It's sent the public parameters. It hasn't calculated the secret yet, but when it receives a response from the client, it will calculate the secret and it can start doing the encryption. So we'll draw the next message and then see what the client does. So what do we get? So the server's done. Now let's look at what the client does. The next message contains actually multiple handshake messages. The client key exchange and we'll see some others eventually encrypted. This is the client key exchange. So the previous one was the server key exchange message. This is the client key exchange. What does it include? The Diffie-Hellman parameters from the client. Remember, Diffie-Hellman, there's alpha and q. They were sent from the server to the client. YS, the public value from the server, was sent also. And then eventually the client, when it receives them, it chooses its private value, X of the client, calculates its Y value, YS, sends it back to the server. And this message from client to server contains that value of Y from the client. It's listed here, the public key of the client in this case. So this is the Y of the client coming back. 128 bytes or 1,024 bits is the length of the public value in this case. So let's make note of that and then look at the next two. And once... So from the client's perspective, it receives alpha, q. It can now calculate... It chooses its private value, X, calculates YC and sends that back to the server. It can also calculate the secret. So to note here, we have some secret between the client and the server. And when the server receives this key exchange message, it can also calculate that secret, KCS. This is the Diffie-Hellman secret shared through that algorithm. Because if you remember back to the algorithm, we calculate based upon the Y values and the X values. And they both get the same value. That was the idea of the Diffie-Hellman algorithm. So after sending this, the client knows KCS and when the key exchange is received by the server, the server knows or can calculate KCS, they now have a shared secret, which was the aim of this key exchange steps. They'll use that to encrypt their data, but they'll not use it directly. It's a little bit more complex than that. Let's look a little bit about what happens with those secret values. So there's one secret value, which is called the master secret. Actually, it's called slightly different. This is a bit too much detail. It's called the pre-master secret. So this value that we just calculated using Diffie-Hellman is called the pre-master secret. And then there's an algorithm defined that both of them will follow that says we take that value, combine it with some other values, such as the random bytes that were sent in the first messages, use some hash functions and generate another secret. And the idea is to create a secret, which is eventually the master secret, which will be used for other steps. We will not go through the exact algorithm for converting the pre-master into a master secret, but it combines the... It uses some hash functions. It's known by both sides, including the attacker, and the output is really a master, the master secret. And both sides will get the same value, because the algorithm that they follow is the same. Then that master secret will then be used to generate another secret. Secrets for doing the encryption and secrets for doing the Mac. So in the steps for encrypting the data, which we'll see shortly, there's not just one key used. Remember, our AES uses one key, a Mac function uses a key, and they should be separate for security. We should use different keys for the different operations. So we need two keys there. Some of the algorithms, remember, the modes of operation sometimes have an initialization vector. They are usually kept secret and generated as random bytes. So I think if that's another secret value generated. So again, we take this master key and apply a known algorithm to generate multiple different secrets as output. And essentially what it does is it takes the relatively short master key and produces random bytes, and some of those random bytes are used for the different keys. So the master key is combined with... If we go back to the start, these random bytes from the client and also the random bytes from the server, they are all combined together plus random bytes and using some hash functions. And we don't need to know the detail. It's in the specification, but using some hash functions, it produces as an output different keys. The encrypt key, a MAC key and IVs, initialization vectors and even some other values that may be used for other operations. It actually uses different keys for each direction of data encryption. So I will not list it here, but this master plus the random bytes which were exchanged at the start are all input to a function that produces many keys as output. There's an encrypt key for the data that browser will send to the server. There's a separate key for decrypting from what the server sends to the browser so that each direction, they have a different key for encryption. Similar, they have a different key for the different directions for applying the MAC. So in fact, there are two MAC keys, two encrypt keys, two initialization vectors. They are all generated from this master which actually came from the pre-master which was obtained using Diffie-Hellman. I will not draw it for the server, but because it uses the same input and they apply the same algorithms, they'll get the same keys as output. So they both know the same set of keys. So where do we get to with our protocol? That happens. That's processing at the browser and the server, the client and server. Inside this message, there was the client key exchange and as a result of that, after that the browser now has a set of keys that it can use. So the next message it sends is this special change cipher spec. This is just saying to the other side, let's swap from doing the key exchange to now start to use those keys that we just generated. The encrypt key, the MAC key and so on. This is telling the other side it's time to change to the other keys. And from then on, we'll use those keys to encrypt the data. So there's another message that comes. But if we try to look at the contents, we don't see it. It just tells us, Wireshark tells us, this is an encrypted handshake message. It's encrypted with a key which we cannot, we don't know, we've captured, we don't know what the key is. So we know it's a message sent from client to server, but we don't know what the contents of that message are because it's encrypted using the keys that we just generated. So we'll write that. So we had a change cipher spec and then this last handshake protocol message. Anyone want to guess what this one is? Let's go back. So this, from the client, client kicks change, change cipher spec. And this one is from Wireshark's perspective that was us capturing the packet, intercepting. It can't see what it actually is, but we know from the protocol how it's defined what it probably is. If we go back to our slides, there's an example of what the exchange normally contains. Where is it? Here. We, let's see what we've seen. The hello message from client and server. The server sent a certificate to the client. Then a server key exchange. Hello's at the start. Certificate, server key exchange. This diagram shows the general case where a certificate is sent from server to client. In addition, the client sends a certificate to the server. But that's optional. And it's not normally used for web browsing. With web browsing, we only have a certificate stored at the server and send that to the client. This client, your web browser doesn't have its own certificate. So in fact, there's no certificate request. The next message was the server hello done. We skipped this phase three because there's no certificate sent from client to server. We got the change cipher spec and then finished. So the client's actually sending finished. I'm done. Finished the handshake. So this last one here would be an encrypted finish message. But note it's encrypted when we look at it in Wireshark. That's the finish of the handshake step. What comes after that is the data for the application. From the client, we had client key exchange, change cipher spec, then this encrypted handshake message which we think is the finished message. Even though we cannot see it in Wireshark, we know based upon the protocol operation. What happens next? Almost done. This is from the server back to the client. There's this handshake protocol message called news session ticket. This is a new feature in TLS. So if you look at our slides, it doesn't contain that message in there. So in one of the recent versions of TLS, this was added. So we'll come back to that later. Let's assume, let's skip over it for now. We'll see its purpose when we finish the handshake. So in fact, from the server's perspective, it sent the server hello. It sent the certificate, the server key exchange. There was no certificate request. It sent server hello done. Then change cipher spec and then finished. So these last two messages, change cipher spec and finished, are here. Change cipher spec. Let's start using the other algorithms and the keys related to them. And then this is the finished message, but it's in fact encrypted. We can't see that when we capture. There was this one in between, news session ticket, which we'll return to shortly. Let's draw them to finish this. Those last three messages, news session ticket, change cipher spec. Let's switch to the other ciphers and now we're finished, but that last one was encrypted. And we'll go see the summary. But now, there are no more handshake messages. The handshake is complete. We now start sending data from, in this case, from browser to server and in response. And in Wireshark, we see that as simply listed as application data. We know it's application data, but let's look at it. So this is from the browser computer to the server. What's inside? It's a TCP packet going to port 443. It's going to the secure web server. So someone who intercepts knows that. What's inside? Random characters. That is, we cannot see what's inside. We know, because we know that it was web browsing, that this is actually the HTTP get request. Remember that HTTP get request, get this URL and maybe some fields. That's what this packet is. But we don't know what the details are. We don't know the URL. We don't know what the fields are inside that header because it's all encrypted and also a MAC is implied. And subsequent messages are just listed as application data. And again, if we look at the details, we'll see that that's just encrypted packets or encrypted payload. Anyone want to guess what these messages are? So this is most likely the HTTP get request from browser to server. This may be a TCP ACC coming back. Actually, no. The TCP ACC is not encrypted. This could be the response coming back, the HTTP response including the web page coming back and some other encrypted data that we could be sending multiple packets. There may be later requests for other resources as well. And that's it. So these messages are the application doing its job. In this case, the web browser sending a request and the server sending back the web page. And the purpose is that we hide that information from anyone who intercepts the packets. We'll not draw them because now it moves on to the encrypted data. We're just drawing the handshake. Actually, what happens next is the data. The data flows in both directions, but it's encrypted. There's also some messages at the end to close the connection. We'll not draw that. So at the end to close the SSL connection and the TCP connection. Any questions about the handshake protocol? This diagram is a specific instance of this one on the slides. So this is the general case if there is a certificate from client to server. But what we saw is a specific case where that certificate is not included. With a slight variation of this new session ticket. So let's explain that. Let's look at the rest of the capture. Slightly later there's another client-hello, server-hello. And some more application data is exchanged. Client-hello, server-hello and more. Why? Remember when you visit a website, you download that web page. There may be images included. So then you request the image, download the image, request the style sheet, download the style sheet and so on. So usually there's not just one request. And then you may follow links and so on. All between your browser and the same web server. So in SSL we normally for every TCP connection we need to do this handshake. If we go back and see the TCP packets as well. What most likely happened is that this is the end of the first connection, the TCP connection. We finish the connection. And then we do a SINAC, an act to set up another TCP connection from browser to same server. To request the second resource, let's say the image or the style sheet. And then we do a client-hello, server-hello and go through the handshake again. Now the problem with this is that every time we want to request a resource from the web server, not only do we need to set up a TCP connection, those three SINAC SINAC act, we also need to do all of these messages. So in theory if we need to do this for every TCP connection, then there's a significant overhead. Normally with TCP we need to send three packets to set up the connection before we can send data. But now with SSL we send those three plus another, what, one, two, three, four actually in both directions. One from browser to server, one from server back to browser because they can be combined. And then client back to server and then back to client again. And extra two round-trip times at least are needed there before we can send data. And that can incur a significant delay in our web browsing. Every time we want to download a resource from the web server, the SSL has to exchange these messages. And that includes introduce a delay which the user may start to notice. That's a problem, the performance issue here. There's a small optimization that can be achieved and that was the role of this new session ticket. The idea with SSL is once you establish a session for the first instance, you exchange some information like the certificate. But subsequent access between that same client and server you don't need to exchange all the same information again. You reuse what you've exchanged in the past. So within a session you have multiple separate connections so that you don't have to go through all of these steps again. And this new session ticket is just some way for some information about that session to be stored by the client. And we see it if we go back and see SSL. In the first instance we talked to the server. We had hello, the response back. So we had four exchanges at least between browser and server. But the next time the client and server need to talk, there's a hello message in both ways. Then direct on to change cypher spec. We don't need to send the certificate again and we can keep using the keys that we've established from the previous step. So it saves time for doing the data transfer. So that's the idea of the session in SSL. Once we've established a session we can reuse information related to that session. And subsequent requests you only see really hollows in both directions and then directly change cypher spec. So there are optimizations to try to cut down the round trip time between client and server. Let's try and finish on SSL and just recap on what we've gone through. We said that for every TCP connection we have an SSL connection but we can group a set of SSL connections into a session. And the performance optimization is you don't need to exchange new keys for every connection. You can keep using them within a session. So that's one concept. We've spoke that for the application data we will break it into fragments, optionally compress. A MAC is attached. So we calculated a MAC and attached that and then encrypt all of that and send that with a header across the network. There are different algorithms that we can select from for each of those steps and we've seen one example of those algorithms. Not just the structure of those messages which is a bit too much detail. And we've gone through a specific example of the handshake protocol. There are different variations of that. We've just seen one case. You can use different algorithms and you may see slightly different messages in those cases. These are the list of messages but in the recent versions of TLS there's new messages. We've seen new session ticket as another one that's not listed here. This one's a bit old. We've gone through that procedure but a subset of those steps and let's just recap now on how that fits into HTTP which I think we've said already but repeat again. HTTPS is simply HTTP over SSL or TLS. So it just uses SSL as we've gone through. One of the practical things that we already know, the URL uses HTTPS as the scheme as opposed to HTTP. That tells your browser before you send the HTTP get request set up a SSL connection. The web server listens on a different port than the normal unsecured web server, port 443. It encrypts when we encrypt our request. The URL is encrypted. When we get a response, the entire response, the web page is encrypted. Any forms that we submit, you type in your username and password on a form in HTML and press submit all of that information is encrypted because that's part of the HTTP request. Cookies which are used to maintain state between different requests are included in the HTTP messages so they are encrypted and all the header fields are encrypted. So someone who intercepts when HTTP S is used cannot see any of that information. The browser confirms it's the correct server it's talking to using certificates. The server sends its certificate to the browser using SSL. We saw there was a message where it was sent and the browser reads that certificate and tries to verify it. Just returning to our capture, that message in our exchange was if we go up in here and the certificate is actually included inside here. So 1,134 bytes and the values of the X509 certificate are included there. It's signed by the issuer. We may get to see what type of certificate. In this example, the certificate is issued to a subject by the issuer. The issuer is the authority who signed it, who issued it. It's self-signed in this case. So this is a self-signed so the first time you visit that website you do get a warning. So that comes up there. Your homework task will be to generate a certificate. A real certificate which will not be self-signed but the authority will be me. So what you'll do is you'll get me to sign it. I will sign it as the authority and we'll see how that works with web browsing. You'll see it in the assignment but the way that that works is what you do is you generate your own key pair, public-private key pair, which you already have, don't you? I hope you kept your private key.  A special file that you send the authority, me, and I check that. It includes your public key and then I sign it if I trust it. It's the right one. So you send me a request, then I sign it and that generates your certificate. So I create your certificate and return it to you. So that's how we'll see the certificates are issued through an authority. So we'll see that in the next and final homework. How does the server know that the client is the right person? Usually using passwords as part of HTTP. That is, how does the server know it's Steve logging into it? Well, if they submit the correct username and password that was registered on that web server, the server assumes it's the correct person. So the authentication of the client is done not using SSL normally, but using, say, the login, the username and password in a form, which is just sent in the HTTP request from browser to server. You can authenticate clients using certificates, but it's not very common. Not in web browsing, at least, because it requires the user to generate a certificate, and to be associated usually with that computer or browser. So we know the basics of HTTPS and, more generally, secure sockets layer and transport layer security. Let's finish with one final example about a different protocol and one that you've used, I know, Secure Shell. Just remind ourselves of what Secure Shell is used for. Remote login is the general name of the application. In the past, in the old days, there was what's called Telnet. Telnet was a protocol and an application that allowed us to connect from one computer or login from one computer into another remote computer. Telnet had no security features. Everything that we sent using Telnet was not encrypted, it was sent as plain text, and when we logged in, so when you log in, you must type in your username and password, you type it in on your local computer, they are sent to the remote computer which verifies or checks that you can log in, that information is sent unencrypted with Telnet. So Telnet allowed you to access a shell on another computer, so Secure Shell does effectively the same thing, was intended to do the same thing, but all in a secure manner. It used encryption and forms of authentication. Secure Shell also supports file transfer and tunneling, that is, what's the command to copy securely between computers? SCP, Secure Copy, which is just built on top of Secure Shell. So it actually uses Secure Shell to do that copy. So Secure Shell allows you to log into another computer or to issue commands on another computer, so we can do that to do copy a file also between two computers, Secure Copy. What number does the Secure Shell use? The port number of Secure Shell server is 22. So a Secure Shell server uses port 22. And in this case Secure Copy is also using port 22, it's actually just built on top of Secure Shell. And the secure file transfer is referred to as SFTP. It's still built on top of Secure Shell, it's just think of a file transfer protocol but on top of Secure Shell. And that makes it easy because you still just need a Secure Shell server for it to work. Secure Shell was originally created by some company but became a standard developed by the Internet Engineering Task Force and there are multiple protocols involved. We will not see the details as much as SSL. There's a general transport layer that does all the encryption and authentication like the SSL record protocol. There's an authentication protocol. So we can authenticate the different sites and some ways to manage the connections. Once we establish a connection to reuse those connections for different purposes. We'll show an example of tunneling. And it all operates over TCP. How is authentication performed in Secure Shell? There are different ways to do it, but one approach is that the server has its own key pair, public-private key pair. And we assume that the client knows the server's public key. Somehow it's obtained the public key. So when there's an initial key exchange with Secure Shell, similar to SSL, there's a key exchange up front, then the server, to prevent a man-in-the-middle attack, the server signs the message for that key exchange that it sends to the client. A man-in-the-middle attack happens when we exchange those messages for public key cryptography like Diffie Hellman, but we've got no way to verify that one we received is from the correct person or not. Maybe it's from some man-in-the-middle. So the idea of signing the message is such that the receiver can verify it did come from you, not from someone else. So what happens? The server signs a message in the key exchange with its... What's wrong here? Private key. I seem to always make the mistake. The server signs the message with its private key and the client, assuming it knows the public key of the server, can verify. But a common problem is how does the client know the public key of the server? And when you first log into a computer using Secure Shell, you'll often be presented with this warning and you may see a message, do you really want to trust this connection? You have to type in yes or no. That is because you as the client don't have the public key of the server. So you can't verify that signed message. So it's asking you, do you really want to trust this? Maybe a man-in-the-middle attack is occurring and if you say yes, then you accept the public key of the server and verify it when it could be actually an attack. So to avoid that problem, you actually have to have the public key of the server on your client before you do that connection. So when you type yes in that warning message, maybe it's an attack taking place. There are two main ways in which the server knows it's the correct client, too far, key-based and password-based. Password-based is what you've used a lot in the computer labs. You secure Shell into a server and then it prompts you for the password for that account on that server and you type in the password. If it matches the correct one, then you're logged in. So that is the server authenticating the client using the password. But there's another approach where you can also use public-private keys. The client has its own key pair and if the server knows the client's public key, then the client, when it initially logs in it, authenticates by signing a message and then the server knows it's the client because only the person with the correct private key could have signed that. So that allows basically password less log-ins to a server using keys. And in the lab, you use secure Shell. Client authentication was password-based. When you need to log into another computer, you type in username, student, password, student. So the server verified based upon that. You know, when I rebooted your computers all through the lab, that required me to log into every computer and run a command. I didn't type the username and password every time. I used key-based login. I'd set up in advance a key on the client, my computer, and I loaded the client's public key on each destination computer so I could run a command with secure shell without typing a password because it does a key exchange and the client verifies itself by using its private key. That can be more secure in that there's no exchange of passwords and no one can log in by guessing your password. This is a general diagram of the secure shell exchange. We first established a TCP connection, SIN-SINAC-AC. There is an exchange of two initial messages from client to server and server to client saying something about what protocol they're using, what version of secure shell. Then there's some key exchange messages between both sides to negotiate the algorithms to use. Similar to SSL, you can select from the algorithms available. You perform a key exchange. We'll see an example where we again use Diffie-Hellman to key exchange. Once you exchange a secret, you say, let's move on and start using that secret to encrypt our data and then it moves on to the data encryption finally. The general procedure is similar to SSL in that we say hello to each other. We negotiate algorithms to use. We do a key exchange and then we encrypt data using that secret or something derived from that secret. We will not draw it, but I'll open a capture for secure shell just to illustrate some of those concepts. Let's directly filter for SSH. This was done before. It was between the... In this case, this is the address of the server. There's 203 address and 192 is the address of the client. The first two messages are saying, what version of SSH do we support? Because they both should accept... They may have some minimum version which they know is secure, so they need to know that they're both using the acceptable version. Then there's some initialization of the key exchange. This is not doing the key exchange. This is saying what algorithms will we use for key exchange? And here's the client, for example, saying some combination of algorithms that we use. So similar to SSL, we say these are my preferred algorithms. And it lists the algorithms for key exchange, Giffy-Hellman variations, the algorithms for encryption, AES, and others. And we encrypt with different algorithms in both directions, and the algorithms for the MAC, HMAC with MD5, SHA1, and so on. So this is the negotiation of algorithms. The server does the same, and they agree upon some algorithm to use. In this case, they chose our favorite, Giffy-Hellman for key exchange. And what it starts is that the client sends to the server a request for the Giffy-Hellman parameters to get started. Then the server replies, and in the reply, there's the modulus and the base. Remember, Giffy-Hellman alpha, the base to the power of some private value x mod q. Alpha is the base, q is the modulus. Here they're labeled, instead of alpha is G, and instead of q, it's P. So it's just the notation of the protocol in this case. So this is the modulus, this is the value of alpha. And these are public values, and alpha is often quite small or fixed, whereas the modulus may be quite large, usually 1,024 bits, I think. That's the alpha and q for Giffy-Hellman, and the client responds, what does it send? It's public value, y of the client. Remember, Giffy-Hellman, we have alpha and q, we choose x, calculate y, send y to the other side. Well, the value of y here is this one. It's called e in the protocol here. The public value of the client and the server sends back its public value. Here the server f, we called it ys, when we did calculations with Giffy-Hellman. So now they have exchanged their values of y, they calculate their secrets k, and now can encrypt things with the secret k. And in this message from the server, it's calculated the secret k and actually has encrypted some keys that it's going to use. The encrypted value is shown here. The structure and the actually, if you go along, you'll see this is all encrypted. So it's a key encrypted by the server. What key did it use to encrypt the Giffy-Hellman secret? Use Giffy-Hellman to establish a secret, use that secret to encrypt some other secret. And the result, the ciphertext is shown here. And there's also some signatures for authentication, which are shown in this field. So it's again another application of this concept. Use a public key algorithm to exchange a secret, Giffy-Hellman in this case. Then we'll generate secrets from that and use those to encrypt our data. And then finally, we say, okay, let's start encrypting our data with a new set of keys, the ones we've just exchanged or based upon them. And everything from then on is just encrypted packets. Someone who intercepts cannot see the contents. We can see the ciphertext and the MAC. The MAC is not encrypted in this case, but we cannot see the contents. So we cannot see what commands you type when you're using secure shell. We cannot see you type in the password or what the password value was when you sent it to the server. It's all encrypted. Port 22 is used by the server here. So there was some identification string to say who we are, what version of the protocol do we support. We negotiate algorithms. We do a key exchange, for example, with Giffy-Hellman. And then at the end of that key exchange, we generate new keys from the shared secret. Here's the algorithm in general to do it. You generate a new key using the shared Giffy-Hellman key and some other parameters. We don't need to go through that algorithm. And then they can start to encrypt data using that new key that's generated. There are many different algorithms supported. So this is a list of some of those algorithms supported by secure shell. And I think that's a good place to stop because we still have a little bit left to go, but we need to go through some more complex examples just to finish this. We'll do that next lecture on Friday. So we'll just recap on this, give an example of using secure shell, say for tunneling, and explain the concept of tunneling. And that will finish us for the course. So we'll continue that on Friday.


So if we're going to talk about the process of blood clotting or hemostasis, stop the bleeding, then we have to talk about our platelets. Platelets, I'm back to histoland. I'm back to feel good happy land because I wanted to remind you of what platelets actually look like. These things, they look like dirt on your slides. Remember back in the day when you were hunting for it, you were doing the Easter egg hunt for blood cell types.  They come from the giant megakaryocytes that are so huge that they can't actually squeeze out into the bloodstream, but they want to.   So they're not really cells.  Like they have little pieces of endoplasmic reticulum, and they've got little pieces of mitochondria and a few ribosomes. So they can do some stuff. They don't live very long, probably because they don't have any cell parts to take care of all their needs. Platelets are something that when you go donate blood, they'll often ask you, pretty please with sugar on top, will you just donate platelets?  They leave most of it in there, they just take out the platelets. And you get kind of cold in that process, and you get to sit there for half an hour, or for two hours and like watch movies and stuff. Yeah, I'm in. I would totally do it. Apparently, I and lots of women, which is really interesting, have a antibody in our systems that is associated with increased respiratory issues, with blood transfusions. And so we're not actually, there's a whole herd of us that are not allowed to donate platelets in that manner. We can donate whole blood though, which I think is really interesting. Okay, so little fragments that play a role in clotting, and in this next section, this is going to be a long one, we're going to look at the whole process of clotting and clarify the role that the platelets are actually playing. Let's see if I can find the off button.


Discipline in the Japanese Tefl classroom. My experience in teaching English to young learners is based in Japan. At the start of my time teaching, my student group consisted of two children of the same family. The siblings are a boy age 5 and a girl age 3, who participate equally in the English conversation sessions. Three main factors of this situation present difficult walls, preventing forward progress. Those three factors are distracting objects, counterproductive classroom philosophies, and personality conflicts. Lesson duration considering the age. First, the English conversation takes place in the children's home and playroom which is full of toys. The sheer multitude of playtime objects means that keeping the attention of the children during the allotted time is difficult. It's understood that at these two very distinct age groups any activities should not be extended too long. Despite the glaring differences between lesson planning for a 3-year-old and a 5-year-old, one of the commonalities is that activities and lessons should be kept simple and short. If they're excessive, the students will lose interest, motivation, and they will make no progress. The children's mother wants to prioritize their time playing as opposed to strict studying. While this is appropriate for the children's age group, maintaining discipline and stable attention in a sea of toys is difficult. My solution to this problem is to be flexible in my lesson planning, incorporating whichever toys or games the children are momentarily infatuated with. If they express enough restlessness, I try to entice them with a different toy or game which is connected to a lesson I had planned. Parents' expectations. Second, as I mentioned briefly above, the children's mother has a specific image in mind for the lessons I teach. Her priority for the lessons is for the children to enjoy themselves. Despite this environment, both of the parents mutually express a desire for the children to demonstrate enough English capability to enroll in a foreign school within two years. With both of these standards, set by the parents and my direct employers, I need to make sure each lesson balances relaxation and productivity without sacrificing the primary objective, fun. My counter to this is to make sure that the activate phases outweigh the study phases of each activity. During the study phases, I prioritize group work where the five-year-old and the three-year-old complement each other's strengths. As often as possible, I create games which have a dynamic of the two of them working together to solve puzzles, or play creative games as a team while I roleplay an opposing force. During the games and puzzles, I try to elicit English from them both. Where one struggles with English, I ask the other to help without spoiling the answer. Of course, this is one specific example of the general structure I use to overcome the playtime focus imbalance dilemma. Classroom communication. Third, the most difficult to overcome issue impeding progress in our classes, is the personality and maturity conflict between the two children of the class. I am tasked with addressing both children simultaneously, lest one become jealous or disengaged and cause upset. The five-year-old boy is shy and easily irritable. Still in the swings of the mind developmental stage. For this reason he is easily thrown into temper tantrums, and crying fits when his younger sister becomes more involved with the toy he's using than he likes at the moment. The three-year-old is enamored with her older brother, and often wants to be involved with whatever he's doing. When the children get too on top of each other and cause a ruckus, unfortunately I'm not the only present authority, responsible for conflict resolution. The children's mother is a presence involved in each lesson by-by-her-preference. This means that when the children need a disciplinary correction, I'm not the active authority of the lesson. Considering the frequency with which the boy has temper tantrums, classroom disruptions are plentiful. This is my area of study and my next step of growth as a teacher. My experiments are still yielding results. I'm working on learning how to attract the children's attention during their disputes, create equal shares of playtime with the toy of the moment, and moving beyond conflict to the next game or activity which will distract the children, and encourage them to forget their conflicts. There is room for improvement in this section of the job. Do you want to teach English abroad? Take a TEFL course today. Properly managing discipline in the classroom is a challenge which every teacher must learn to conquer. Regardless of whether the setting for the lesson is a traditional classroom or an in-house playroom, a teacher must be prepared to keep the students engaged and under control while the lesson is in action. Despite roadblock distractions, such as excessive toys, a split in the classroom power dynamic, or difficult to manage children, teaching young learners must always be an engaging and flexible process which has room for just as much energizing fun as it does for language development. Thanks so much for watching. We are ITTT, the leading provider for TEFL and TESOL training courses. If you like this video, please subscribe by clicking that button down here and click on any of the videos here on the left for more interesting teaching tips for getting certified to teach English abroad and online.


I win, I win, it's all I can really say about it, as a game it was awful. Before a game, Carlo Ancelotti made one change to the start on the 11th, Anthony Gordon dropping out and Bernard coming in on the left hand side. I thought Everton, for the opening 15 minutes, I thought he got old with the game. OK, I thought we came out and we got a grip of the game. But some of the passing in that first half was atrocious. Tom Davis and André Gomez, as a pair, just gave the ball away unnecessarily, under his passes.  And it's really frustrating, we did a watch-along for the game and everyone who will have seen me and Pett in our air out really with the amount of times we just give the ball away unnecessarily. I think for Everton to be a better team, we've got to learn how to keep hold of the ball. And if there's nothing on, play it down the line and we've got two centre forwards who will chase things, so give them something to run after. Because otherwise we're passing balls back along our line, not really going anyway. First half, it's difficult to kind of think of anything positive in the first half, you know. I thought Dom and the Calvert looming put himself about. I was really disappointed in Retialis and today I just don't think he had a good game at all, couldn't get into it. Dom had the best effort really with a turn and a shot which was straight at the goalkeeper then caused Tim Currell. Any problems at all. Norwich at the other end, you know, Hernandez was there, was there main threat. He ran at us a couple of times and had a shot which took about two deflections in it, the outside of the post. And then they had a shot just before half time which Jordan Pickford pushed away. Other than that Norwich, you know, they set up well, he kept the ball better than we did at times but without really hating us. I mean, we got in at the break and, you know, me and Pett were ffuming at that time just because it's just deteriorated. And again, you wanted to see Everton really assay at themselves, it deteriorated. Second half, obviously Calamantialotti made a change at that time. Guilfee Sigginson coming on for Tom Davis and he took Daleks of Wobby in a little bit. And that kind of got Everton going in the second half. We had the shot early on from Retialis and got a corner from it. And we just grew into the game and we got the goal, good ball by a Wobby to Coleman. He got a corner, Luke had been whipped it in and Michael came with a good header, flick header into the far corner to give us the lead and for the next 15, 20 minutes Everton controlled the game and it was like, this is exactly what we want to see. Moving Norwich about and then the drinks break came. They made a couple of changes bro, Pukion and Bwendir and Campwell came on. And they kind of got, we let them back into the game, we let them back into the game by being sloppy in possession, just making the wrong decisions at times. Instead of playing a ball to a teammate, trying to do drag backs or nutmeg people and we were giving the ball away and that enabled them to edge closer. And the closest they really came was a free kick for Bwendir, put it in and Andre Gomes, I think it was stabbed it wide and it was just those nervous moments and we could never really create anything clear cut to put the game to bed. Anthony Gordon came on, Moise Keane came on and got the quickest book in Ever with a trying to super backflicked in and having to go in for a slide tackle and getting injured and Gordon, you know, trying to get into it but couldn't quite get into it. Leighton Baines came on, but some great play by Moise Keane after initially trying to dribble out of our box, got us a free kick and Luca Dean put the free kick over and that was really it for us, we saw it out, a very difficult last six minutes but we won the game and Calamante a lot of you look at it, you know, 54% possession, more shots than Norwich, Swelton and I, five on target but it'll be the victory and the clean sheet that'll please the Italian more than anything because it wasn't a good performance but we've won the game and four-pointing in three days since returning to Premier League action. Everton up to 10th at the moment and now only, remarkably only four points off Seventh Place and three behind Sheffield United so job done, not a great performance but a good win. Make sure you subscribe, give the video a thumbs up and if you want more videos join us on Patreon. See you later.


Bonjour à tous, good morning everyone. The first thing I want to talk about today is what we're doing to support indigenous people during the pandemic. Since day one, our government has been engaging with First Nations, Inuit and Métis nation leaders in the fight against this virus. We've been listening to people's concerns and working with local leadership to ensure that communities are getting the right support. And so far, we've taken a number of important steps. We're investing in emergency shelters to help indigenous women and children fleeing violence. We're offering interest-free loans and non-repayable contributions to help indigenous businesses weather this storm. We're helping First Nations, Inuit and Métis nation students and recent grads find a job this summer. And last week, we announced more funding to support the most urgent needs of indigenous communities dealing with the COVID-19 outbreak. While all communities have had to wrestle with COVID-19 these past few months, the everyday realities of this crisis are different for everyone. To mount an effective response to this crisis, we must adapt our approach and our programmes to recognise and meet the particular needs of all indigenous peoples, including those living in urban areas and off reserve. To this end, we announced $15 million back in March to support indigenous organisations that deliver services to these populations as part of the Indigenous Community Support Fund we had set up to help prevent and mitigate the impact of this virus. With this money, organisations have been able to give meals, groceries, clothing and supplies to those in need and offer mental health counselling. They've also provided personal protective equipment and cleaning supplies for support of housing and computer and laptops so kids can keep up with their schoolwork. This funding is helping vulnerable people like youth, women and elders. Indigenous community organisations in our cities and off reserve do crucial work year-round but these days their services are in high demand because of the pandemic. We need to make sure they have the resources to adapt and grow their services so they can fulfil their important mission. So today our government is announcing an additional $75 million in new funding for organisations that address the critical needs of the over a million indigenous people living in urban centres and off reserve. This is critical work. If you live off reserve or in a city, we're working to make sure you don't fall through the cracks. You need and deserve services that are culturally appropriate and that's what we're doing with today's investment. Today, our government is announcing a new $75 million investment for organisations that address the critical needs of over a million indigenous people living in urban centres and off reserve. It's money that community organisations can use to fight food insecurity, support vulnerable people, help young people at risk, provide mental health services and prevent family violence. I now want to address the employers and business owners. We're talking a lot about the reopening of the economy these days, which is good news for everyone.  So we're setting up measures to support you. If you need help to re-embrace your employees, you can use emergency wages. We've just extended the program until the end of summer. If you have problems with liquidity, or if you have expenses to take, you can get a loan from the emergency account for businesses. And if you're not familiar with these two programs, I invite you to address your regional development agency. It will be able to help you. We also work with the provinces, territories, housing owners and their locators to lower the rents of small businesses. The owners will be able to provide a demand from Monday to Friday on the site of the Canadian mortgage and housing company. We all hate that life takes its course, but in order for it to happen, everyone must do their part, and the employees in particular have an important role to play. When people think back to normal, one of the first things that comes to their mind is to go back to work, to find a certain financial stability, to see their colleagues and friends again, to take back the routine. Your employees count on you, your community too. So if you need help, but you don't know where to start, go to Canada.ca and consult the page on COVID-19. You will find more information on the programs at your disposal and the way to get support. Our government is there for you. We are already preparing for the recovery of our economy, and I know that together, we will return in force when the crisis is over. As we gradually and carefully restart some activities, it's never been more important to follow public health instructions. COVID-19 remains a very serious health threat. Yesterday, Dr. Tam said that whenever physical distancing is not possible, Canadians should wear a non-medical mask or face covering when they go out. I want to remind everyone that physical distancing means keeping a two metre distance with others. As we start to reopen the economy, it might be more difficult to maintain that distance at all times, so please follow Dr. Tam's advice. Keep washing your hands, stay home, and if you need to, wear a mask. This is the best way to protect both yourself and others. While we are gradually reopening the economy, we must not forget that COVID-19 remains a serious threat to health. Yesterday, Dr. Tam said that Canadians should wear a non-medical mask when they can't keep a two metre distance from others. As we start to reopen the economy, it might be more difficult to respect physical distancing rules. It is therefore important to continue to follow Dr. Tam's advice. Wash your hands, stay home, and if you need to, wear a mask. This is the best way to protect our health and those of others.  Today, more than 230 new officers are graduating from the Royal Military College of Canada. They are part of a new generation of exceptional women and men ready to serve our country with distinction. You have chosen to step up and serve your country, and we could not be more proud of you. Thank you for your example. Thank you for your dedication. Thank you for your love of this extraordinary country. And mostly, thank you for everything you will do for us in the coming years. Congratulations to the Class of 2020.


All of us want faster technologies, smaller devices, cheaper equipment. The lifespan of a computer in 1995 was about five to seven years. Today, it's under two years. I believe that in order to make technology sustainable, you need to have a lot of forethought into what happens at the end of life and consider the whole life cycle of technology development. As technology accelerates, so does obsolescence. And at the current rate of obsolescence growth, there are 40 million tons of e-waste being generated around the world every year. A majority of the e-waste is either landfills or center-developing countries like China, India, or Ghana in Africa, where people recover residual value using informal recycling practices. But the challenge is that these practices are extremely hazardous, both for health and the environment. We asked ourselves, are we resigned to seeing this as a humanitarian disaster? And then as we looked closer, what we realized was there's actually a tremendous opportunity. What we're working on is fighting a way to economically recover value using environmentally sustainable practices. And so our vision is to create a distributed set of mini-refineries, and we're deploying new technologies adapted from the mining industry in order to be able to extract value from e-waste. Our goal is to be able to harness technologies, to be able to turn this away from being a humanitarian disaster into an economic opportunity, which can benefit these societies. We want to no longer see a city that takes in over 1 million tons of e-waste. We want to empower this city to recognize it's sitting on a $2 billion e-mine.