Termination

[00:00:00]
>> Jem Young: Security. None of this matters if you can't secure your system. Bad actor can break in and you have this beautiful auto-saving, storing, read, write, replica strategy, and they just muck around with it and ruin all of that, destroy all your backups. So security is something it's easy to forget because you implement it once and you do it well, you don't have to think about it as much, but it's something you always have to keep in mind.

[00:00:27]
The primary means of securing is just using HTTPS. So that's HTTPS secure. So HTTPS is like putting your data in an armored car and driving down the street instead of walking down the street. So nothing can get to it until it gets to the final destination. And when it gets there, you know, we have to think in system design. What do we do? We have to terminate that connection somewhere, because we could have this armored car drive all the way through the windy roads, all the way back to the database and then unload it, but that's not going to be most effective, because it's going to be slow, it's going to be unwieldy.

[00:01:02]
Every single stop along the way, every server has to look inside and be like, is this for me? No. So we generally want to terminate that connection somewhere, and that's what it's called, termination. So by termination, we have to decrypt the traffic. And you need a certificate to do that. So every endpoint, that's a termination. So every one of those load balancers versus proxies has to have a certificate in it.

[00:01:25]
Certificate is what gets sent to the client. The client encrypts that data using certificate, using a hash, and sends it back. Only we can decrypt it because we have the other side of the key. If you want to know more about public key encryption and all that, Full Stack for Front End, Version 3 now by Jem Young. We'll talk about that. But generally thinking, generally speaking, HTTPS is a pretty good security mechanism for moving your data across the public internet.

[00:01:54]
So when we started building our to-do app, we had our web server doing all this. I was encrypting the request, the requests, processing it and re-encrypting it. And that's something you have to think this is going on. Do I need a separate service to do this or should I have an authentication service doing all this? So encrypting and decrypting is considered a pretty slow process. It's very computationally expensive.

[00:02:18]
All cryptography is computationally expensive, that's the nature behind it. That's why you can't break, I don't know, RSA-2, what's a good encryption algorithm? Anybody. SHA-512. SHA-512. That's why you can't break it because it's computationally expensive to break. That's the whole point. So even when we can decrypt things, it's still going to be a little slow. And this is all in here because you can't forget this costs something, and at small scale, totally fine.

[00:02:48]
Millions of scale, why is my server so slow? Oh, it's encrypting and decrypting millions of requests a second. Ah, it's slowing us down, maybe we should think about what to do with that. So when it comes to termination we have different strategies we can apply. We can terminate the load balancer or API gateway reverse proxy. That's generally what we've been doing. It's generally what most things do.

[00:03:12]
We can terminate the application level, which means the load balancer is just proxying that request through until the actual service that needs it, the service decrypts it. When would we do that? Remember I said the armored car scenario, it's actually a pretty good metaphor for it. And he said, oh yeah, it's much easier to just unload the armored car and put it in something faster. So it's not, you know, slowing down your system, but when is the case when you want to keep that data encrypted through the whole process?

[00:03:47]
Well, encryption at rest and encryption in transit, it depends on how much you have to encrypt. Yeah, HIPAA compliance, so it's one, the data has to stay encrypted the entire way through until it gets to where it needs to go, then it's decrypted. Any other service can be able to read that traffic. That's up, you can say anything involving money, any sort of banking transaction, you probably want to keep encrypted the whole way through because remember, every step along that way, there's a million services, or not a million, but there's a lot of services.

[00:04:17]
You have your logging service, you have, what do we have, our autosave service. You have a variety of things that are reading that request, and you don't know what necessarily they're doing with it. And you can either do a deep inspection on that application or that server saying like, what does it do with the request? I want to make sure nothing's funny happening. No one's changing, no one's pulling an Office Space.

[00:04:43]
You know, just round off all those pennies into dollars, no one's seen the movie Office Space. Yeah, I mean, you have to think there could be a bad actor at your company. And if you didn't encrypt your transactions, pretty easy to shave off a penny or two and then modify the request and then pass it along and no one would ever know. Unless you have really, really good auditing. Or you can trust no one and be paranoid and you just keep that encrypted all the way through and you don't have to worry about it anymore.

[00:05:12]
Another big gotcha is logging services. We didn't touch too much on logging, but assuming we're logging everything, what's the log going to have? The log's going to have information about the contents of that payload. Essentially, the log is just making a copy of that request. If that request contains private information or financial information, now you have this giant exposed database of logs, which most people can access, but it's got a bunch of private information that shouldn't be there.

[00:05:39]
That's a, everybody gets bitten by this. I've gotten bitten by this. We're logging like a password, because we forgot to like, you have to clean your logs or you have to clean all this stuff out. So again, it's something you want to think about, hey, it's so much easier to terminate at the load balancer at the edge, but maybe you don't want to. And then you have option 3, probably less common, which is you can terminate the load balancer, read it, and the load balancer makes the call on, actually, this is sensitive information, I'm going to re-encrypt it and send it along the way, or actually, I'm just going to route this to the API server, it doesn't need to be encrypted.

[00:06:13]
You could do that too, but you know, the trade-off is that's computationally expensive, now your edge server is doing a lot in this case. Is option one best for compliance? Compliance of what they had referenced HIPAA. But compliance to HIPAA or financial. No, if it's, generally if I, I get, I'm not up on my compliance, but you want to encrypt that the entire way through just to be safe. It is more expensive on your system, but it's more on the safe side.