1
00:00:00,000 --> 00:00:14,480
Hey everyone and welcome back.

2
00:00:14,480 --> 00:00:18,920
Okay so we have a lot of cool things to get to within this Fairy Scale.

3
00:00:18,920 --> 00:00:23,920
The very first thing that we're going to be talking about is how we can introduce encryption

4
00:00:23,920 --> 00:00:26,600
into our web server.

5
00:00:26,600 --> 00:00:32,039
So let's actually talk about some of the concepts that we have to understand with respect to

6
00:00:32,039 --> 00:00:36,280
our encryption and then we'll walk through some configurations.

7
00:00:36,280 --> 00:00:40,800
Now the first thing I will say is that the type of encryption we're going to be looking

8
00:00:40,800 --> 00:00:43,359
at is something called SSL.

9
00:00:43,359 --> 00:00:47,840
This is the secure sockets layer and this is the type of encryption that you're going

10
00:00:47,840 --> 00:00:52,880
to find in your web browser when you happen to speak to your website in an encrypted

11
00:00:52,880 --> 00:00:59,520
format that will either be SSL or the newer version TLS which is transport layer security.

12
00:00:59,520 --> 00:01:01,880
Ultimately we're basically talking about the same thing.

13
00:01:01,880 --> 00:01:06,040
We're talking about having an encrypted connection over the web.

14
00:01:06,040 --> 00:01:11,359
So a few points to note here is that when we are talking in an unencrypted fashion we're

15
00:01:11,359 --> 00:01:13,640
going to be using HTTP.

16
00:01:13,640 --> 00:01:19,400
This is the Hypertext Transfer Protocol and this is going to operate typically using the

17
00:01:19,400 --> 00:01:22,120
default port of port 80.

18
00:01:22,120 --> 00:01:27,400
Now when you want to establish an encrypted connection with a web server you're going

19
00:01:27,400 --> 00:01:34,439
to be using the protocol HTTPS which stands for the secure version of HTTP and when you

20
00:01:34,439 --> 00:01:39,360
make this request the default port you're going to be using is port 443.

21
00:01:39,360 --> 00:01:44,719
So again if you happen to be hosting a web server and you are using these particular

22
00:01:44,719 --> 00:01:50,280
protocols you maybe have to pay attention to your firewall rules to perhaps allow traffic

23
00:01:50,280 --> 00:01:52,840
using these particular port numbers.

24
00:01:52,840 --> 00:01:58,359
Okay so here is the deal we have a few things that we have to discuss to understand how this

25
00:01:58,359 --> 00:02:01,120
exactly is going to be implemented.

26
00:02:01,120 --> 00:02:08,520
So we have a way to verify the authenticity of a server and this is via the use of what

27
00:02:08,520 --> 00:02:10,560
is called a certificate.

28
00:02:10,560 --> 00:02:15,120
Now in order for us to be able to implement this type of solution what we're going to

29
00:02:15,120 --> 00:02:18,639
have to do is to use something called a certificate.

30
00:02:18,639 --> 00:02:24,039
Now this certificate is going to allow us to provide our HTTPS service.

31
00:02:24,039 --> 00:02:27,199
This is going to be part of the encryption process here.

32
00:02:27,199 --> 00:02:32,159
Now one distinction we have to understand with respect to our certificates is that we

33
00:02:32,159 --> 00:02:38,399
can have either what is called a self signed certificate or we can have a certificate that

34
00:02:38,399 --> 00:02:42,759
has been signed by a CAA certificate authority.

35
00:02:42,759 --> 00:02:48,279
Now when you happen to have your certificate signed by a certificate authority it gives

36
00:02:48,280 --> 00:02:54,039
you strong verification that the server you think you're talking to is who they say they

37
00:02:54,039 --> 00:02:57,000
are so this is good for validation here okay.

38
00:02:57,000 --> 00:03:03,920
Now you can still provide HTTP services using a self signed certificate but understand

39
00:03:03,920 --> 00:03:09,280
that inherently this is less secure purely because that these could be spoofed and you

40
00:03:09,280 --> 00:03:14,719
may be talking to someone who is not who they say they are and this could be a potential

41
00:03:14,719 --> 00:03:19,479
attack vector for someone like city hacker who is performing a man in the middle attack.

42
00:03:19,479 --> 00:03:25,520
So let me just briefly explain the process of how this is going to happen between a website

43
00:03:25,520 --> 00:03:29,479
and a user and how the encryption transaction actually happens.

44
00:03:29,479 --> 00:03:35,560
Okay so over here we can have our user computer this could be you on your PC or your Mac whatever

45
00:03:35,560 --> 00:03:41,919
it may be and you want to talk to a web server let's just maybe say this is youtube.com okay

46
00:03:42,280 --> 00:03:43,719
let's say YT.

47
00:03:43,719 --> 00:03:49,479
When I happen to type youtube.com into my browser here my browser is immediately going to go

48
00:03:49,479 --> 00:03:55,560
and make a request to this server we already know the process of using DNS to look up the

49
00:03:55,560 --> 00:04:00,399
domain name to the IP address once we do this we can establish this connection.

50
00:04:00,399 --> 00:04:05,519
So we make this initial request specifying that we want to have an encrypted connection

51
00:04:05,519 --> 00:04:07,519
over HTTPS.

52
00:04:07,520 --> 00:04:12,520
Now what is going to happen at this point the server is going to receive this request

53
00:04:12,520 --> 00:04:17,319
see that we want to use HTTPS and it's going to respond in this manner what it's going

54
00:04:17,319 --> 00:04:25,800
to do the server is going to send to you something called its public key in conjunction with

55
00:04:25,800 --> 00:04:27,280
its certificates.

56
00:04:27,280 --> 00:04:33,280
Now this certificate in the event of someone like say youtube.com this is going to be signed

57
00:04:33,279 --> 00:04:37,559
by a certificate authority verifying its authenticity.

58
00:04:37,559 --> 00:04:44,479
So now this browser here has this certificate that has been digitally signed by the certificate

59
00:04:44,479 --> 00:04:48,599
authority as well as the server's public key.

60
00:04:48,599 --> 00:04:54,839
Now not to go into too much of the specifics but your browser is actually able to verify

61
00:04:54,839 --> 00:05:00,359
this certificate authority because your browser has been built to include all of the major

62
00:05:00,360 --> 00:05:06,680
certificate authorities public keys and this actually allows you to verify that the certificate

63
00:05:06,680 --> 00:05:12,120
that you have just been sent has indeed been signed by those certificate authorities and

64
00:05:12,120 --> 00:05:19,600
that gives you confidence that the certificate that was sent by youtube has indeed been verified.

65
00:05:19,600 --> 00:05:25,680
So really now let me just clear my screen the user here like I say has this public key

66
00:05:25,680 --> 00:05:30,560
and the certificate here verifies that we know we're talking to the server who says

67
00:05:30,560 --> 00:05:32,120
they are youtube.com.

68
00:05:32,120 --> 00:05:37,560
Now before we proceed any further I think it's worth making a note on public key and

69
00:05:37,560 --> 00:05:39,720
private key cryptography here.

70
00:05:39,720 --> 00:05:45,879
When we're talking about using a public as well as a private key the type of cryptography

71
00:05:45,879 --> 00:05:48,920
we're talking about is called asymmetric.

72
00:05:48,920 --> 00:05:52,480
So we're going to be using asymmetric cryptography here.

73
00:05:52,480 --> 00:05:56,600
Now let me just talk about what these two keys actually do because this can be a little

74
00:05:56,600 --> 00:06:01,240
bit confusing at first but once you get the concept it does stick in your head.

75
00:06:01,240 --> 00:06:07,240
With respect to a public key and a private key these keys are ultimately linked together

76
00:06:07,240 --> 00:06:08,240
okay.

77
00:06:08,240 --> 00:06:14,319
So what we can do is we can encrypt data with our public key so that if you have a little

78
00:06:14,319 --> 00:06:19,520
text file and you run it through the public key it's now going to be this encrypted garbage

79
00:06:19,519 --> 00:06:25,159
so to speak unreadable nonsense until it is decrypted but the cool thing is is that

80
00:06:25,159 --> 00:06:31,079
when you encrypt something with a public key you can no longer decrypt it back with the

81
00:06:31,079 --> 00:06:32,079
public key.

82
00:06:32,079 --> 00:06:37,240
So imagine it like this imagine you had a house key that you could lock your door with

83
00:06:37,240 --> 00:06:40,079
so you leave the house and you lock the door with your key.

84
00:06:40,079 --> 00:06:45,439
Now imagine that that key could no longer open the door you had to have a completely separate

85
00:06:45,439 --> 00:06:47,359
key that could unlock it.

86
00:06:47,360 --> 00:06:50,560
This key can lock something but it can unlock it.

87
00:06:50,560 --> 00:06:56,680
In order to be able to unlock that door we would have to pull out a separate key entirely

88
00:06:56,680 --> 00:06:59,040
this would be a private key.

89
00:06:59,040 --> 00:07:03,319
Now this might seem a little bit weird why on earth would we want to be able to have

90
00:07:03,319 --> 00:07:08,560
such functionality whereby we can encrypt something with a particular key but we can't

91
00:07:08,560 --> 00:07:10,879
decrypt it back with that same key.

92
00:07:10,879 --> 00:07:17,040
Well imagine this imagine you have two people here so this can be John and this can be Trevor

93
00:07:17,120 --> 00:07:21,080
and John and Trevor want to communicate in an encrypted fashion.

94
00:07:21,080 --> 00:07:28,000
So John wants to send Trevor a message so imagine John wrote up a little text file with a little

95
00:07:28,000 --> 00:07:32,320
private message and then John encrypted it with a particular key.

96
00:07:32,320 --> 00:07:38,640
So John sends this message over which is fully encrypted but Trevor here has a problem he

97
00:07:38,640 --> 00:07:44,480
has successfully received the encrypted message but Trevor now needs to know the encryption

98
00:07:44,560 --> 00:07:48,720
key that is going to be used to decrypt that message.

99
00:07:48,720 --> 00:07:54,280
So John has this issue how do I actually securely send Trevor the encryption key.

100
00:07:54,280 --> 00:07:58,680
So this can be the message this can be the key because think about it imagine someone

101
00:07:58,680 --> 00:08:02,040
was actually spying on this transaction.

102
00:08:02,040 --> 00:08:08,000
So when John sends Trevor the message that is encrypted the person spying on this conversation

103
00:08:08,000 --> 00:08:10,400
sees this encrypted message.

104
00:08:10,399 --> 00:08:15,279
Now right now they can't actually read this message because this message is encrypted but

105
00:08:15,279 --> 00:08:21,519
as John actually sends Trevor the key the attacker now has the encrypted message as well

106
00:08:21,519 --> 00:08:26,639
as the encrypted key therefore they can use this key to decrypt the message and read what

107
00:08:26,639 --> 00:08:28,679
John sent to Trevor.

108
00:08:28,679 --> 00:08:33,759
So this is the problem here we want to be able to find a way that we can securely share

109
00:08:33,759 --> 00:08:37,919
information that isn't going to compromise this transaction.

110
00:08:37,919 --> 00:08:41,639
Now this is exactly what asymmetric key encryption is going to do for us.

111
00:08:41,639 --> 00:08:48,000
So let's reimagine the transaction once again we've got John on the left here and we have

112
00:08:48,000 --> 00:08:49,559
Trevor on the right.

113
00:08:49,559 --> 00:08:54,759
Now imagine the same process in action John wants to send Trevor a secret message how

114
00:08:54,759 --> 00:09:00,000
on earth are we going to solve this now Trevor here is a smart cookie he has an idea he suggests

115
00:09:00,000 --> 00:09:02,199
we use asymmetric cryptography.

116
00:09:02,199 --> 00:09:07,519
So what Trevor does is he generates a private key and a public key.

117
00:09:07,519 --> 00:09:13,799
Now his public key is exactly what it sounds like it is public it can be shared with absolutely

118
00:09:13,799 --> 00:09:18,600
anyone it doesn't matter who sees it the only thing that matters is that Trevor keeps his

119
00:09:18,600 --> 00:09:24,079
private key private to himself so Trevor could send me an unencrypted email or publish on

120
00:09:24,079 --> 00:09:27,639
his website his actual public key okay.

121
00:09:27,639 --> 00:09:32,960
So I could just read what this public key is and then use it to encrypt my own message

122
00:09:32,960 --> 00:09:38,120
so this message once again is I'm going to take it and encrypt it with Trevor's public

123
00:09:38,120 --> 00:09:44,400
key now like I say once I lock the door I encrypt this message with this public key

124
00:09:44,400 --> 00:09:49,240
I can no longer decrypt that message myself I can't decrypt it back using the public

125
00:09:49,240 --> 00:09:54,879
key so think about this now our adversary is watching the transaction once again now

126
00:09:54,879 --> 00:10:01,080
I send this message to Trevor that is now being encrypted with Trevor's public key and

127
00:10:01,080 --> 00:10:05,960
think about this what can the adversary actually do the adversary can actually see the message

128
00:10:05,960 --> 00:10:11,160
they can see the public key but the public key can't be used to decrypt this message

129
00:10:11,160 --> 00:10:17,000
it can only be used to encrypt messages to Trevor now when the actual message gets to

130
00:10:17,000 --> 00:10:23,240
Trevor encrypted with this public key Trevor can now decrypt it because he has the private

131
00:10:23,240 --> 00:10:27,680
key which is associated with this public key so that the only person who can decrypt the

132
00:10:27,679 --> 00:10:34,879
message is Trevor so everyone who sees Trevor's public key can send encrypted messages to him

133
00:10:34,879 --> 00:10:41,000
but he is the only one who can ever decrypt that message so that is the concept of asymmetric

134
00:10:41,000 --> 00:10:47,079
encryption however we also have the concept of symmetric encryption now symmetric encryption

135
00:10:47,079 --> 00:10:53,159
really is like your house key the key that can lock your door can also unlock your door

136
00:10:53,159 --> 00:10:58,679
now the advantage here of symmetric encryption is that it is way way way faster than asymmetric

137
00:10:58,679 --> 00:11:05,000
encryption now the reality is with respect to our SSL here we're actually going to be using a

138
00:11:05,000 --> 00:11:10,519
combination of both so let's revisit what we talked about there now that we understand a little bit

139
00:11:10,519 --> 00:11:15,959
more about the process that's going to happen so remember we have our user here we have our

140
00:11:16,040 --> 00:11:23,879
YouTube server we have just sent a request for HTTPS and the server has sent back its public key

141
00:11:23,879 --> 00:11:31,160
as well as its certificate which has been signed by a certificate authority and our browser is able

142
00:11:31,160 --> 00:11:37,720
to verify this now that we have the public key for YouTube what our browser is going to do now is

143
00:11:37,720 --> 00:11:43,480
something really quite smart the browser is going to generate a session key this is going to be an

144
00:11:43,480 --> 00:11:49,879
encryption key just use for this session between the client and the server now this session key

145
00:11:49,879 --> 00:11:55,560
is actually going to leverage symmetric encryption now here is the cool part what the browser is

146
00:11:55,560 --> 00:12:02,759
going to do after it generates this key it's going to actually encrypt this key using the public key

147
00:12:03,320 --> 00:12:10,840
that the server just sent to us so that means we can actually send this session key over to the

148
00:12:10,840 --> 00:12:16,680
server and anyone who is watching this transaction can't actually read it because the session key

149
00:12:16,680 --> 00:12:22,759
has been encrypted using the public key of the server meaning that no one can decrypt this

150
00:12:22,759 --> 00:12:28,759
apart from the server who has the private key so now the server gets this encrypted message it

151
00:12:28,759 --> 00:12:35,720
decrypts it and now the server also knows the session key so now we successfully have symmetric

152
00:12:35,720 --> 00:12:41,399
encryption in place the user happens to know the session key and the server happens to know the

153
00:12:41,399 --> 00:12:45,879
session key and nobody else who is watching the transaction is going to be able to know that

154
00:12:45,879 --> 00:12:52,360
information and from now on we can have this two-way communication using symmetric encryption so I

155
00:12:52,360 --> 00:12:58,279
know this is a lot to deal with we have certificates and certificate authorities and we have public

156
00:12:58,279 --> 00:13:03,639
keys and private keys and symmetric encryption and asymmetric encryption all of this can take a

157
00:13:03,639 --> 00:13:09,080
little bit of time just to sink in and fully clarify within your head but understanding these core

158
00:13:09,080 --> 00:13:15,000
concepts is going to be absolutely crucial to being able to understand what exactly is going on

159
00:13:15,000 --> 00:13:21,000
when we configure our server to use SSL so now that we have some of these core concepts under

160
00:13:21,000 --> 00:13:27,080
our belts how about we begin creating these certificates and configuring your server to use

161
00:13:27,080 --> 00:13:31,399
these certificates and well that's what we're going to be doing in the very next nuggets I hope

162
00:13:31,399 --> 00:13:38,120
this has been informative for you and I'd like to thank you for viewing