Results 1 to 9 of 9
  1. #1
    Newbie
    Join Date
    Jun 2018
    Posts
    6

    Default Possible to sniff the broken traffic?

    I will start with what I am trying to accomplish. I am running UT at home and am going to setup a full pcap system. I understand that for internal communication I will need to use a span port on a switch.

    The issue I am facing is capturing the decrypted SSL traffic while it is broken by the SSL Inspector application. In the event IPS or whatever else flags on something I want the capability to go and look at the data.

    I have tried tcpdump on all the interfaces of the UT box itself and result still seems to be encrypted SSL traffic. I have done this with tcpdump itself and the troubleshooting app on in the GUI (which appears to just be tcpdump but I was trying to be thorough). This leads me to believe that UT is likely doing the decryption and re-encryption in memory.

    Has anyone else successfully set up a similar solution?

    Any information or experiences you are willing to share is appreciated.

  2. #2
    Untangle Junkie dmorris's Avatar
    Join Date
    Nov 2006
    Location
    San Carlos, CA
    Posts
    17,431

    Default

    Quote Originally Posted by yeahright View Post
    This leads me to believe that UT is likely doing the decryption and re-encryption in memory.
    Correct, you aren't going to find any unencrypted traffic on any interface.
    Attention: Support and help on the Untangle Forums is provided by volunteers and community members like yourself.
    If you need Untangle support please call or email support@untangle.com

  3. #3
    Newbie
    Join Date
    Jun 2018
    Posts
    6

    Default

    Thanks for the reply.

    Is there any practical way to accomplish capturing that traffic that you are aware of?

    Going down the road of even attempting to pull it out of memory in real time is not going to end well.

  4. #4
    Untangle Junkie dmorris's Avatar
    Join Date
    Nov 2006
    Location
    San Carlos, CA
    Posts
    17,431

    Default

    Can you describe what you are trying to accomplish?
    Attention: Support and help on the Untangle Forums is provided by volunteers and community members like yourself.
    If you need Untangle support please call or email support@untangle.com

  5. #5
    Newbie
    Join Date
    Jun 2018
    Posts
    6

    Default

    Sure.

    Ultimately the goal is to accomplish full packet capture of my entire network. A significant portion of this can be accomplished with a span port on a switch.


    However, some of the most important traffic from a security perspective is what is egressing the network on 443.

    For the sake of this thread what I am trying to accomplish is to capture the traffic SSL inspector is breaking, while it is unencrypted and store for later analytics.

  6. #6
    Master Untangler
    Join Date
    May 2010
    Location
    Texas, USA
    Posts
    629

    Default

    I sincerely hope that Untangle can not / will not let you do that. That would be a completely inappropriate feature to have in the product.

  7. #7
    Newbie
    Join Date
    Jun 2018
    Posts
    6

    Default

    Why would you consider that inappropriate?

    That capability is ultimately what gives inspection of SSL real value in my eyes. There are of course legal matters to consider if you were to configure this in a business environment. You would have to exempt certain categories of traffic from being inspected (medical, legal, finance etc.) With those exemptions in place I see no issue with having that capability. In fact a number of products do allow it. You also of course add it to the disclaimer that nearly every company uses when accessing their IT systems. They inform you that your activities are subject to monitoring

    My background is in incident response as well as having been part of several red teams.

    If I am responding to an incident, the ability to see what exactly was in the traffic that was alerted on is invaluable. It is the difference between knowing that something bad might have happened and knowing that someone ex-filtrated xyz intellectual property or secret documents or whatever your company or organization may be trying to protect. As I am fond of saying, attackers typically do not turn on the "evil bit" in their packets so being able to see the traffic adds tremendous value.

    I would go so far as to say without a capability like this that SSL inspections value is diminished significantly. All it allows for is signature based detection which is less than perfect at best and a slightly enhanced ability to categorize web sites.

    From an security and incident response perspective that is a repetitively small return on investment considering the amount of effort required to deploy SSL inspection in a large environment.

    Having been on teams who's job it was to play the adversary, the network security teams ability to see our traffic was one of the largest concerns we had. As an attacker, if all of my traffic just turned into clear text, I am much easier to detect.

    If your opposition to this is related to privacy concerns, I totally get it and agree it has potential for abuse. That same abuse potential exists in monitor of phone calls and emails on a corporate network.

    Personally I am what some consider a tin foil type about privacy. I will not use social media due to privacy concerns. That being said, when any of us click the OK button to login to a corporate system that has a disclaimer informing us that we are subject to being monitored, we have given up that privacy in that environment.

    In this case, and perhaps I should have articulated my situation a little more completely, I am doing this on a home network lab.

  8. #8
    Master Untangler
    Join Date
    May 2010
    Location
    Texas, USA
    Posts
    629

    Default

    You answered your own question on why it is inappropriate - there are massive legal implications in doing this. There are also considerations that have to be made on any UNINtended uses for that capability - you are only considering that INtended use case...
    Last edited by JasonJoel; 06-25-2018 at 08:19 AM.

  9. #9
    Newbie
    Join Date
    Jun 2018
    Posts
    6

    Default

    I acknowledged the legal implications. However, they are not really more significant than the ability to monitor someone's emails or phone calls. These both have the same potential of misuse. It is trivial to profile someone's web traffic or to read their emails. In the wrong hands this can obviously be used against someone. That is also true of the monitoring nearly everyone already does. The legal risk and whether or not to accept it ultimately falls on the organization or owner of the infrastructure and data.

    The unintended uses are exactly what I am considering. The bad guys are doing various attacks using functionality similar to this. Implementation on a network if nothing else can help the sysadmins better understand what this might look like if used as an attack.

    The capability already exists in the product. SSL Inspector breaks the traffic, scans it and re-encrypts and reports on it. All I am talking about is capturing the full packet. Not any different than the comparison of only being able to see the sender, recipient and subject line of an email versus see those and the body of the text in that email.

    As to making everything work while doing this, yes it certainly is a significant undertaking with unique challenges. That is why if it is going to be attempted, you want as much value out of that effort as possible. My background is much more security than network engineering so I am sure there are practical challenges in keeping everything working that I cannot fully appreciate.

    I agree that content control at the border is indeed at least on life support. This capability allows some visibility back into it. It is not a catch all solution, nothing is. It is simply one more tool to assist in securing an environment.

    As a person that comes from the point of view of a red team. SSL is a god send. It makes us much harder to detect adversarial behavior. It pushes detection measures back into the internal network which is even more difficult than boundary detection. Even more so because most of what we do in playing the attacker looks like typical network and especially Windows behavior and traffic.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  

SEO by vBSEO 3.6.0 PL2