I love to mess around with Linux in my home lab and I like to check out the state of Samba from time to time. I originally wrote this article for Ubuntu 14.04 and it has been one of the most popular posts on this blog, so I have updated it and fixed a few things that have changed over the years. There is a screencast that accompanied the original post on YouTube outlining the process for 14.04. Largely the process is the same except for a few more dependencies(see the apt-get sections) and I cleaned up the testing with smbclient. I chose Ubuntu because they have pretty recent packages of Samba, more info about binary packages for different Distributions on the Samba Wiki. If you are following this as a guide, I’m assuming that you have already installed Ubuntu 16.04. If you do watch the screencast for 14.04, it is best viewed in HD!
When you put your credit card into a website what happens to it? The goal of this article is to explore some of the possible answers to that question.
With all the changes that are happening in the payment card industry these days, I’ve been thinking about security around it. EMV/Chip and PIN is coming and there are weird things happening around NFC/ApplePay/Google Wallet/Tap to Pay. There have also been a lot of breaches in the last year, that are really helping expose the weaknesses in how this data is stored and transmitted. This post is really more a thought experiment about how you store hashed information “securely”.
Have you ever wondered what would happen if you tried to connect to a website that was serving a certificate chain way longer than normal? I know, me too. Often times security research is about thinking outside the box, and this is just one of those times. Plus we might learn a few things along the way.
I’m new here. What is a certificate chain?
When you connect to a secure website, your browser uses a TLS certificate to verify the authenticity of the connection and to help set up the encryption of the connection. The way that you know that the certificate is valid is either because you have seen it before and saved it as a remembered certificate(this is common in a self-signed certificate situation or with SSH), in most cases someone else that you trust “signs” the website’s certificate. Allow me to use Star Trek The Next Generation characters(source) to illustrate how this works. If you meet Ensign Tony at Ten Forward, the next time that you meet him you will know who he is based on what he looks or sounds like. This is how self-signed certificates work.
Read Full Article
A while ago Google announced its project zero, which is a team of security researchers, whose goal is to find bugs in software, so that you, dear user, can use the web and technology securely. They were very up front about how the team would work. They would report bugs and vulnerabilities that they have found to the companies or people responsible for maintaining the software. Google would give the developers 90 days to fix the bug and then let the world know about it.
It turns out that Microsoft Windows has a few bugs in it(who knew?). On more than one occasion Google discovered vulnerabilities in Windows. On two of these occasions Microsoft was notified of these vulnerabilities and was “unable” to patch the vulnerability before the 90 days elapsed. I have read many articles about this and I feel like they are almost all completely out to lunch. I won’t even link to them because I feel they are so poorly informed on this topic.
Read Full Article
What is Firesheep?
You may remember about 4 years ago Eric Butler released a Firefox extension that did something very clever. It hooked into a packet capture library and could capture cookies that weren’t sent over SSL, at an open Wi-Fi access point. That extension was Firesheep. The press grabbed onto this story as it made “hacking” into someone’s Facebook account something almost anyone could do. At the time, many sites would shuttle you securely over https:// for the login and then give you an authentication cookie that was served insecurely over http://. This authentication cookie is the thing that proves you are who you say you are so if a bad guy got access to this cookie, they could easily impersonate you on that site.
I have been testing out different ways to optimize this site for performance, purely as a learning experience. I have come across several guides explaining how server-side caching works, some of them are really good, and some of them a bit out of date in terms of what I consider “best practice” in the industry these days. Most of the guides to server side-caching do not include the notion of SSL/TLS. Just like setting up a web server with SSL/TLS is more complex than setting up a web server without, setting up a cache with SSL/TLS is more complex than setting up a cache without. The goal of this article is to discuss some of the most popular methods and some of their advantages/disadvantages.
This article will be more about the overarching concepts and flow of information than actual configuration, but I’m hoping to do articles on how to actually configure the different options in future posts and incorporate them into this article.
Read Full Article