<?xml version="1.0" encoding="UTF-8"?>
<rss xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/" version="2.0">
  <channel>
    <title>topic Re: WSL and SSL decryption in General Topics</title>
    <link>https://live.paloaltonetworks.com/t5/general-topics/wsl-and-ssl-decryption/m-p/515815#M107137</link>
    <description>&lt;P&gt;&lt;a href="https://live.paloaltonetworks.com/t5/user/viewprofilepage/user-id/176029"&gt;@MD-OTL&lt;/a&gt;,&lt;/P&gt;
&lt;P&gt;In a default WSL install it simply sends traffic out the connected interface, so there's nothing to identify and separate out WSL traffic from the client traffic itself. WSL can be treated just like any other Linux client though, so I would simply make them install the certificate that you're using on your firewall so you can decrypt the traffic appropriately. Then the only exceptions that you're making are the same that you'd be making for any Linux endpoints already in your network.&lt;/P&gt;
&lt;P&gt;&amp;nbsp;&lt;/P&gt;
&lt;P&gt;We do this two different ways:&lt;/P&gt;
&lt;P&gt;1) If you are smart enough to manage your own WSL instance (and you're a member of a group that actually allows you to install it) than go for it. We aren't making any special exceptions for your WSL instance that wouldn't need to be made otherwise.&lt;/P&gt;
&lt;P&gt;2) If you aren't technically inclined enough to setup WSL to meet our requirements (but you are a member of a group that is approved to use WSL) we'll spin you up a managed Linux server for you to use were we directly manage it and it'll already work within the environment.&amp;nbsp;&lt;/P&gt;</description>
    <pubDate>Fri, 23 Sep 2022 14:08:35 GMT</pubDate>
    <dc:creator>BPry</dc:creator>
    <dc:date>2022-09-23T14:08:35Z</dc:date>
    <item>
      <title>WSL and SSL decryption</title>
      <link>https://live.paloaltonetworks.com/t5/general-topics/wsl-and-ssl-decryption/m-p/515793#M107126</link>
      <description>&lt;P&gt;Hi guys. We have a number of developers that use Windows Subsystem for Linux (WSL) on their Windows clients, and there are a lot of URLs and services that will not work when we decrypt the traffic. Managing a decryption exclude list for them would be a major pain, so I am thinking of ways to fix this. Is there any way to separate WSL sessions from Windows sessions somehow? How do others handle problems like this?&lt;/P&gt;</description>
      <pubDate>Fri, 23 Sep 2022 08:56:34 GMT</pubDate>
      <guid>https://live.paloaltonetworks.com/t5/general-topics/wsl-and-ssl-decryption/m-p/515793#M107126</guid>
      <dc:creator>MD-OTL</dc:creator>
      <dc:date>2022-09-23T08:56:34Z</dc:date>
    </item>
    <item>
      <title>Re: WSL and SSL decryption</title>
      <link>https://live.paloaltonetworks.com/t5/general-topics/wsl-and-ssl-decryption/m-p/515815#M107137</link>
      <description>&lt;P&gt;&lt;a href="https://live.paloaltonetworks.com/t5/user/viewprofilepage/user-id/176029"&gt;@MD-OTL&lt;/a&gt;,&lt;/P&gt;
&lt;P&gt;In a default WSL install it simply sends traffic out the connected interface, so there's nothing to identify and separate out WSL traffic from the client traffic itself. WSL can be treated just like any other Linux client though, so I would simply make them install the certificate that you're using on your firewall so you can decrypt the traffic appropriately. Then the only exceptions that you're making are the same that you'd be making for any Linux endpoints already in your network.&lt;/P&gt;
&lt;P&gt;&amp;nbsp;&lt;/P&gt;
&lt;P&gt;We do this two different ways:&lt;/P&gt;
&lt;P&gt;1) If you are smart enough to manage your own WSL instance (and you're a member of a group that actually allows you to install it) than go for it. We aren't making any special exceptions for your WSL instance that wouldn't need to be made otherwise.&lt;/P&gt;
&lt;P&gt;2) If you aren't technically inclined enough to setup WSL to meet our requirements (but you are a member of a group that is approved to use WSL) we'll spin you up a managed Linux server for you to use were we directly manage it and it'll already work within the environment.&amp;nbsp;&lt;/P&gt;</description>
      <pubDate>Fri, 23 Sep 2022 14:08:35 GMT</pubDate>
      <guid>https://live.paloaltonetworks.com/t5/general-topics/wsl-and-ssl-decryption/m-p/515815#M107137</guid>
      <dc:creator>BPry</dc:creator>
      <dc:date>2022-09-23T14:08:35Z</dc:date>
    </item>
    <item>
      <title>Re: WSL and SSL decryption</title>
      <link>https://live.paloaltonetworks.com/t5/general-topics/wsl-and-ssl-decryption/m-p/515892#M107150</link>
      <description>&lt;P&gt;&lt;a href="https://live.paloaltonetworks.com/t5/user/viewprofilepage/user-id/43480"&gt;@BPry&lt;/a&gt;&amp;nbsp;, many thanks for your answer. Unfortunately many of our developer services use client certificates or certificate pinning and are therefore undecryptable. And it seems like our developers change tools and libraries as often as we change underwear. To maintain a do-not-decrypt list would cause frustration for them and a lot of hassle for us. I was hoping WSL maybe had the same option as VMware Workstation, that you can have different IP address for the virtual NIC of WSL and the physical NIC of the Windows client. I will look into it.&lt;/P&gt;</description>
      <pubDate>Sun, 25 Sep 2022 06:06:50 GMT</pubDate>
      <guid>https://live.paloaltonetworks.com/t5/general-topics/wsl-and-ssl-decryption/m-p/515892#M107150</guid>
      <dc:creator>MD-OTL</dc:creator>
      <dc:date>2022-09-25T06:06:50Z</dc:date>
    </item>
  </channel>
</rss>

