Week 6

This week I decided to try and familiarize myself with many of the standard port protocols. I was intrigued by how many of the ip addresses from teh labs used smtp and I wanted to see what other types of applications also use smtp. Most of my time was spent doing the homework/lab this week so I didn’t get through doing all of the suggested labs from the lectures as I normally do.

SMTP

One thing that was interesting to me was that many of ip addresses used smtp but only one main onse used imap and pop3. This got me thinking that there’s probably a difference between which ones are used to send and receive. Wikipedia says that smtp is often used by clients to send or relay email while, pop3 and imap are used to receive or download emails. SMTP uses a store and forward methodology to hold on to data, so when data is transferred to it it holds on to it until all of the pieces reach it until it is allowed to forward what it’s holding onto.

Rabbitmq and AMQP

I have used a project in the passed called rabbitmq to handle events on it’s message bus. I had misremembered that it used SMTP as it’s protocl, instead it uses a different protocol called AMQP. AMQP or advanced message queue protocol looks to be defined on TCP 5672. Rabbitmq has some really nice docs about how the protocol is setup

Wikipedia put AMQP in interesting terms for me. In the same way that SMTP FTP and HTTP have standardized their area of expertise so that different clients and servers can interact reliably, AMQP does that for the messaging queue domain. It defined many different levels of guarantees such as at most once at least once and exactly once. These can be very important differentiations, as they could mean the difference between sending a recipient no push notificaitons on their phone vs 1000 push notifications by accident.

ESMTP

I also stumbled across a protocol called ESMTP or extended SMTP, which as you can probably imagine extends the SMTP protocol. It adds more features such as non ascii text capabilities with the 8BITMIME mode. I wonder why the creators didn’t submit RFCs to extend SMTP itself instead of creating a new protocol ESMTP. Perhaps it was like http2 in the sense that it was somewhat backwards incompatible, although it would appear the ESMTP handles all of the same funcitonalities as SMTP. Go figure

HTTP vs HTTPS

One area that I’ve always wanted to get more proficient in is the difference between http and https.

Theobvious differences

One of the biggest differences obviously is that http transmits over port 80 where https transmits over 443. The general problem with http is that the traffic transmitted between client and server can be intercepted and read by anyone with enough nohow to sniff tcp packets and patch them together. This becomes especialyl critical with things like passwords and creditcard info.

HTTPS introduces a sercurity protocol to encrypt traffic between client and server using a certificate. I’m not quite sure why its a called a secure sockets layer certificate but I aim to find out!

SSL

Right out of the gate I came across some interesting information. SSL was renamed to TLS (Transport Layer Security), or maybe a better statement would be to say that SSL was the predecessor to TLS and SSL has been deprecated. The book Bulletproof SSL & TLS implies that SSL was renamed TLS for purely political reasons around the internet behemoth of the 90s, netscape. To remove some of the tension around SSL being netscape specific, they changed the name to dissasociate it.

Generally speaking, the connection is connection is initiaited by a cryptographic negotiation between the client and the server. A unique secret is agreed upon at the start of the interaction and is used to encrypt information back to the server, who has the same shared secret and is able to decode. All of this is done before the first bye of data is transferred, so everything sent between the client and server is encrypted.

The secret is never transmitted directly across the network so men in the middle cannot capture that and act on behalf of the client or server. The was called SSL because that’s exactly waht it was doing, securing the socket layer. It would seem the name Transport Layer Security also has the same implications from its name.

Firewalls

I wanted to see how they relate to security groups on aws. They both seem to restrict traffic so I wanted to dig in a bit and see what I could find.

How I understand firewalls, they sit in between networks and restrict traffic between the two. That could be between the internet network and an internal network or even networks between to private networks. Basically between any networks.

AWS security groups also restrict traffic to resources (and are obviously aws specific). They can be ip specific but they dont always have to be. They are slighty more configurable as they restrict or allow based on policies rather which can be attached to clusters or new instances.

From what I can tell, they essentially do the same thing except configuring a security group for your aws cluster is probably leaps and bounds easier than configuring a firewall.

Network security at my job

One of the policies that’s been dicsussing at work is whether or not network security on teh whole the direction we want to go vs role based cryptographic security. The argument against firewalls and whitelisted ips is that given an attacker who knows his stuff and the right opportunity, they will be able to break in to some allowed host and get the keys to the kingdom. The idea behind role based authentication is somewhat different. In the most naive implementation, let anyone access anything they like! However let the services only respond appropriately to requests that are correctly authenticated.

I’m no network security expert but to me this seems like a whole different approach to network security in general. I’m sure that going purely with the second would never be a realistic option, the second would probably encompass both. This week has inspired me to learn more about this topic! I’m going to ask about it at work and hopefully at it to my writeup for next week.

Cheers!