5 ms·

One HTTPS packet? You won't know. But when you add context you can start to understand what traffic is legit. There's really no silver bullet for security, bu

One HTTPS packet? You won't know. But when you add context you can start to understand what traffic is legit. There's really no silver bullet for security, but with a combination of restrictions and data collection, you can raise the bar on the type of attack that can go undetected.

acqq 12y ago
Do try to do it and tell us how many different servers were connected in just one web surfing session where you visit all the sites you visit in one day. I can give you an example of a single page: I've just opened www.yahoo.com and counted 23 https connections and 7 http to different IP adresses. I've removed the multiple connections to the same IP from this count which would otherwise be bigger. Two of those doesn't even have reverse DNS entry. Then think about the fact that the malware regularly appears in the content of the otherwise "approved" adds. You just don't have the metadata to recognize those.
- jethro_tell 12y ago
  Yeah I'm not sure I understand your point. I understand that web surfing generates a ton of connections and I don't think that you can pick a packet out of the pile and say that one is the bad one. I've made that fairly clear. I don't even think we disagree. So I'm confused about what you're trying to get at?
  - acqq 12y ago
    In my opinion the arguments you give, specifically "I'm not advocating Deep Packet Inspection here" and "one HTTPS packet? You won't know. But when you add context you can start to understand what traffic is legit" aren't based on your actual knowledge but just a plain guess. Therefore I give you a specific example of just one page. Moreover, observing "the packet" independent of the connection of course doesn't have sense. But it's you who talk about the single packets, I've given you an example of 30 connections, where each has hundreds of packets. Even observing just the connections as the connections, you can't know which ones are potentially malign unless you analyze their content.
acdha 12y ago
The problem is that this rapidly becomes unworkable for all but the smallest of networks with a huge amount of available time. False positives make this contest incredibly asymmetrical – ever think about how many hours went into developing IDS rulesets looking for malware signatures which were obsolete once people switched from IRC to HTTP? That repeated for HTTP to HTTPS, detecting “unusual” networks rapidly became ineffective as throwaway accounts or compromised hosts became popular, etc. That process will repeat for every single bit of context you add. The worst case scenario for this is full-on steganography – public blogs posting scraped content with commands hidden in images or text statistics, bots searching twitter or subscribing to RSS feeds, etc. and waiting for user-triggered network activity before transmitting so it looks like just one more request in the 100+ made by a modern webpage. For anything other than preventing DDoS attacks this is a slow, futile grind. It's much more effective to focus on preventing an attacker from running code inside your network than trying to clean up the mess after they do so. That's a combination of things like changing the UI to avoid asking the user to make critical security decisions they can't meaningfully answer and, most likely, an app-store like model for most people because even that level of review greatly exceeds what a non-expert can do.

acqq 12y ago

Do try to do it and tell us how many different servers were connected in just one web surfing session where you visit all the sites you visit in one day. I can give you an example of a single page: I've just opened www.yahoo.com and counted 23 https connections and 7 http to different IP adresses. I've removed the multiple connections to the same IP from this count which would otherwise be bigger. Two of those doesn't even have reverse DNS entry. Then think about the fact that the malware regularly appears in the content of the otherwise "approved" adds. You just don't have the metadata to recognize those.

jethro_tell 12y ago
Yeah I'm not sure I understand your point. I understand that web surfing generates a ton of connections and I don't think that you can pick a packet out of the pile and say that one is the bad one. I've made that fairly clear. I don't even think we disagree. So I'm confused about what you're trying to get at?
- acqq 12y ago
  In my opinion the arguments you give, specifically "I'm not advocating Deep Packet Inspection here" and "one HTTPS packet? You won't know. But when you add context you can start to understand what traffic is legit" aren't based on your actual knowledge but just a plain guess. Therefore I give you a specific example of just one page. Moreover, observing "the packet" independent of the connection of course doesn't have sense. But it's you who talk about the single packets, I've given you an example of 30 connections, where each has hundreds of packets. Even observing just the connections as the connections, you can't know which ones are potentially malign unless you analyze their content.

acdha 12y ago

The problem is that this rapidly becomes unworkable for all but the smallest of networks with a huge amount of available time. False positives make this contest incredibly asymmetrical – ever think about how many hours went into developing IDS rulesets looking for malware signatures which were obsolete once people switched from IRC to HTTP? That repeated for HTTP to HTTPS, detecting “unusual” networks rapidly became ineffective as throwaway accounts or compromised hosts became popular, etc. That process will repeat for every single bit of context you add. The worst case scenario for this is full-on steganography – public blogs posting scraped content with commands hidden in images or text statistics, bots searching twitter or subscribing to RSS feeds, etc. and waiting for user-triggered network activity before transmitting so it looks like just one more request in the 100+ made by a modern webpage. For anything other than preventing DDoS attacks this is a slow, futile grind. It's much more effective to focus on preventing an attacker from running code inside your network than trying to clean up the mess after they do so. That's a combination of things like changing the UI to avoid asking the user to make critical security decisions they can't meaningfully answer and, most likely, an app-store like model for most people because even that level of review greatly exceeds what a non-expert can do.