23 October 2019
Jordan Hoffart is Rad
Jordan Hoffart used to be very good at skateboarding. He is still pretty good, but he is a very funny and likeable interview. Enjoy.
19 October 2019
Mark Suciu Verso: (*&(^(&^)(*&@#$%^&*&^^% :: brain broken ::
I have said before that to be truly extraordinary you must not only be able to execute brilliantly, but you must first imagine something brilliant you can execute. That vision, that ability to create, is more rare than the ability to execute.
I was reminded of this fact again when I watched this new video from Mark Suciu. The first 3:30 alone would be the best video part this year, and the video as a whole is an instant classic, easily the best of the year, and one of the best ever. Go here for a good and entertaining reaction from a guy that talks about skateboarding for a living.
Enjoy.
16 October 2019
What is Perfect Forward Secrecy?
This is answered in many places on ye olde interwebbe, but a lot of them are rubbish, or are hiding behind some very terrible web design / advertisements, or both. I aggregated the information from a few different videos (shoutout Computerphile!) and some articles as part of a homework assignment, so I thought I would reproduce it here. Full list of resources is copied at the bottom of the post.
This writeup assumes you know what a client and server is, and care, but if you do not then you can think of the client as anything that sends a request, and a server as anything that sends a response (or 'serves' a response). The confusing thing about the terms is that the roles in a transaction can change: clients can become servers, and servers can become clients. Confused yet? Cool. All you need to know is that one thing is calling another thing, and you don't want anyone to be able to listen in on their chat. The thing that makes the initial call? That's the client. The thing that responds? Server.
Enjoy(?).
Summary
Perfect Forward Secrecy enables you to support secure, encrypted communication between clients and servers in your environment, and reduce your risk in the event that any of your servers is compromised. Unlike typical RSA public/private key encryption, cipher suites that use PFS protect you if your server(s) are hacked and the server encryption keys are exposed.
Consider an Electronic Medical Record system that uses typical (TLS 1.2) RSA key exchange now in wide adoption. The EMR system servers encrypt all message traffic using a public and private key pair; the private key is unique to each server. The message traffic in the EMR system includes records and patient data for tens of thousands of patients, across years of medical history. If the private key for any server is compromised then a hacker may be able to use it to gain access to all of the data on that server: medical data, patient data, and the entire message history.
Now consider an EMR system that incorporates Perfect Forward Secrecy. In PFS there is no link between a server’s private key and the session key, so in the event a private key is compromised then a hacker cannot uncover the session key and decrypt the conversation. Also, if attackers are somehow able to compromise the session key they are only able to decrypt the conversation for that particular session; your conversation history is protected, because perfect forward secrecy forces a new session for each message.
In this example the result of a breach caused by a decrypted session key in a system that integrates PFS is the exposure of a single message. The result of a breach caused by the loss of a private key in a system protected by RSA key exchange is the contents of an entire server.
Benefits
You can use PFS to dramatically reduce the amount of information that is vulnerable in the event of a successful hack, and to deter attacks because the rewards in the event of a breach are minimal. Adopting cipher suites that integrate PFS enables you to stay compliant with the latest and most up-to-date traffic security requirements (for example, Google has enforced PFS by default in Gmail since 2011, and Apple has required PFS support for all new apps in the app store since January 2017).
Drawbacks
Perfect Forward Secrecy forces end to end encryption. If your monitoring solution requires that your messages be inspected then you must incorporate a true inline SSL proxy in order to read them. Passive SSL inspection devices that rely on certificate information, subject alternative name (SAN), or common name/hostname (CN), will not be able to decrypt or inspect any traffic protected by PFS.
Supporting PFS requires more computing overhead, because every transaction requires a unique security key. Also, legacy systems may not support the cipher suite keys required for PFS.
Why Should I Care?
PFS can be implemented today if you use a cipher suite key exchange that supports it (i.e. Diffie-Hellman Ephemeral - DHE, or Elliptic Curve Diffie-Hellman Ephemeral - ECDHE). These cyphers have been available since SSLv3, but it is best to implement the latest and most secure protocol supported by your environment, and to evaluate your security posture if your legacy systems do not support PFS.
The latest Transport Layer Security standard (1.3) mandates PFS for all sessions. In other words, if you want to use the most up to date security protocols for your internet traffic, you must use perfect forward secrecy.
For example, Zscaler supports TLS 1.3 and PFS because it is a true inline proxy: it terminates the SSL connection established by the client and establishes a new SSL connection to the server. You can inspect your traffic and ensure that your network exploits the latest, most robust security standards available.
///
This writeup assumes you know what a client and server is, and care, but if you do not then you can think of the client as anything that sends a request, and a server as anything that sends a response (or 'serves' a response). The confusing thing about the terms is that the roles in a transaction can change: clients can become servers, and servers can become clients. Confused yet? Cool. All you need to know is that one thing is calling another thing, and you don't want anyone to be able to listen in on their chat. The thing that makes the initial call? That's the client. The thing that responds? Server.
Enjoy(?).
Summary
Perfect Forward Secrecy enables you to support secure, encrypted communication between clients and servers in your environment, and reduce your risk in the event that any of your servers is compromised. Unlike typical RSA public/private key encryption, cipher suites that use PFS protect you if your server(s) are hacked and the server encryption keys are exposed.
Consider an Electronic Medical Record system that uses typical (TLS 1.2) RSA key exchange now in wide adoption. The EMR system servers encrypt all message traffic using a public and private key pair; the private key is unique to each server. The message traffic in the EMR system includes records and patient data for tens of thousands of patients, across years of medical history. If the private key for any server is compromised then a hacker may be able to use it to gain access to all of the data on that server: medical data, patient data, and the entire message history.
Now consider an EMR system that incorporates Perfect Forward Secrecy. In PFS there is no link between a server’s private key and the session key, so in the event a private key is compromised then a hacker cannot uncover the session key and decrypt the conversation. Also, if attackers are somehow able to compromise the session key they are only able to decrypt the conversation for that particular session; your conversation history is protected, because perfect forward secrecy forces a new session for each message.
In this example the result of a breach caused by a decrypted session key in a system that integrates PFS is the exposure of a single message. The result of a breach caused by the loss of a private key in a system protected by RSA key exchange is the contents of an entire server.
Benefits
You can use PFS to dramatically reduce the amount of information that is vulnerable in the event of a successful hack, and to deter attacks because the rewards in the event of a breach are minimal. Adopting cipher suites that integrate PFS enables you to stay compliant with the latest and most up-to-date traffic security requirements (for example, Google has enforced PFS by default in Gmail since 2011, and Apple has required PFS support for all new apps in the app store since January 2017).
Drawbacks
Perfect Forward Secrecy forces end to end encryption. If your monitoring solution requires that your messages be inspected then you must incorporate a true inline SSL proxy in order to read them. Passive SSL inspection devices that rely on certificate information, subject alternative name (SAN), or common name/hostname (CN), will not be able to decrypt or inspect any traffic protected by PFS.
Supporting PFS requires more computing overhead, because every transaction requires a unique security key. Also, legacy systems may not support the cipher suite keys required for PFS.
Why Should I Care?
PFS can be implemented today if you use a cipher suite key exchange that supports it (i.e. Diffie-Hellman Ephemeral - DHE, or Elliptic Curve Diffie-Hellman Ephemeral - ECDHE). These cyphers have been available since SSLv3, but it is best to implement the latest and most secure protocol supported by your environment, and to evaluate your security posture if your legacy systems do not support PFS.
The latest Transport Layer Security standard (1.3) mandates PFS for all sessions. In other words, if you want to use the most up to date security protocols for your internet traffic, you must use perfect forward secrecy.
For example, Zscaler supports TLS 1.3 and PFS because it is a true inline proxy: it terminates the SSL connection established by the client and establishes a new SSL connection to the server. You can inspect your traffic and ensure that your network exploits the latest, most robust security standards available.
///
13 October 2019
Read This: Bad Blood by John Carreyou
Holmes and her cartoonishly villainous cohorts managed to con their way into NINE HUNDRED MILLION DOLLARS. That's a lot of money! Apparently more than half of it was spent on legal fees, which raises the question of how much the lawyers collecting those fees (and aggressively suing anyone that dared to speak the truth about this sham) knew about the con, and if the company was actually viable.
It would be great if the lawyers employed by Holmes would admit some culpability, or maybe suffered some consequences for their participation in this very long con, but that did not happen. Lawyers are very good at making sure that they get to bill hours, and everyone else gets fucked.
12 October 2019
Green for Me, Mostly
11 October 2019
I've Been Busy
I've been busy, away, or busy and away at the same time. I was in Detroit, then in Tel Aviv for a week, and then Whistler, BC, then Seattle. On top of that I have been working on some projects for work. So a lot going on, and not super pumped to post any update. I think about doing it, and then I forget because I have some homework or I do not want to look at my computer.
Things have calmed down a little, even though I have more trips on the horizon (LA, Toronto, Seattle again). I will post more regular updates for the balance of the calendar year. Get excited. First things first, here is a photo from the last time I was in Israel. It's a photo of the Old City in Jerusalem. When I was there it rained, and also it was early, and there were no people. The Old City is a tourist trap, but if you can avoid that, and you can get to other parts of Jerusalem, it's great.
More later.
Subscribe to:
Posts (Atom)
