WirelessPhreak.com

I like to travel, f*ck with technology, and partake in the occasional tropical drink.
I am also a co-host on The NBD Show podcast.
Follow Me

Most of the people who have found this post on the internet are already familiar with Palo Alto Firewalls and everything they can do. One of the features I really like is the IPS functionality built into the firewall, but - and its a BIG BUT - if you're terminating SSL after the traffic ingresses your untrusted security zone you're loosing a lot of the PAN's IPS functionality because the traffic is encrypted.

Here is a reference diagram of what I am talking about:

So how do we fix it? PAN has a feature called SSL Inbound Inspection. This feature as of 7.1.x code does not terminate the SSL session or work as a proxy, but at a high-level takes a copy of the traffic and uses your imported certificate and key to inspect the traffic against the policies that have been configured. It's really easy to setup, but there are a couple caveats that I wanted to outline in this post.

SSL and Supported Ciphers: As many of you know the SSL negotiation is determined between the client and the server during the SSL handshake.  Because the firewall does not work as a SSL proxy, or "man in the middle", you have to insure that the client and server negotiate a cipher that the firewall is able to decrypt. This is where we ran into a little confusion.  Much of the documentation on the PAN site is focused around outbound SSL decryption.  This gets confusing when PAN doesn't document what feature they are discussing in an article. For example they have an article of supported decryption ciphers and they did not specify on the document if these were the ciphers used in outbound decryption or inbound inspection.  Then, when I asked for documentation of supported inbound SSL inspection ciphers, they could not point me to a document. FYI if you look at an SSL decryption profile there is a disclaimer in small print that only the listed RSA ciphers are supported for inbound inspection. I was told this was going to fixed.


So to help you out here is what is supported for inbound SSL inspection:

To ensure your firewall can decrypt all inbound SSL traffic it is important you configure your servers or load balancers to only offer ciphers supported by your firewall. If you're using an F5 to terminate SSL here is the string you can define in the cipher list within your SSL client profile.

!DES:!3DES:!SSLv3:!RC4:!EXP:RSA

APP-ID and Application Default Services: Many of you out here have enabled APP-ID on your firewalls and probably leveraged the application default service setting to let the firewall determine the port to allow traffic on.  I have been told application default setting in the services section of a security policy is best practice and, to be honest, I actually like it and use it; but it can break SSL Inbound Inspection. To understand where it breaks we first need to understand how a firewall processes a packet when you have enabled inbound SSL Inspection:

  1. The firewall looks to see if the packet is allowed by the security policy.
  2. The firewall identifies the traffic as SSL
  3. The firewall looks to see if the destination is configured with a SSL decryption policy
  4. If the destination address matches a protected IP address, it is decrypted and processed through the security policies once again as web-browsing still on port 443. 
  5. Bang! Connection is broken.

When you have application default set it is expecting specific ports based on the application that has been identified by APP-ID.  So if you have SSL and web-browsing configured in the APP-ID portion and application default configured in the services portion of your security policy...once the firewall decrypts the packets and runs it back through the security polices as web-browsing traffic on port 443 the firewall drops or resets the connection.

To resolve this issue you can still use APP-ID but you will need to explicitly list the ports the firewall will allow traffic on. This will allow any application, in this case web-browsing traffic on TCP port 443, to be allowed on any of the listed ports.

Configure SSL Inbound Inspection: You can click here to go to the Palo Alto Networks website and they will walk you though the SSL Inbound Inspection configuration.









Friend, co-worker, and guest blogger Matt Krieg owner of Krieg Productions talks about his video setup. You can find him at his website www.kriegproductions.com or check out his youtube channel.

So, you want to be a videographer?
It seems like everyone with a camera wants to make money creating videos these days. But there’s a lot more that goes into video production than you might think. From the monthly software or subscription fees to the thousand dollar stabilizers, the investment needed for professional level video is much higher than you may think. However, that isn’t to say it can’t be done on a budget and I’m going to show you the bare minimum you’ll need to get started in professional video production.

Equipment
Alright - just accept this bitter reality right now - camera equipment is very expensive. Don’t try to cut corners on everything by buying the cheapest gear y
ou can find because you’ll pay the difference later down the road. Trust me. You don’t need a whole lot to get started but you’ll probably end up buying more equipment for each project you take on. Don’t get caught up in all the gear specs right now, if your brand new to videography just understand this one concept on gear. The diminishing return on camera equipment starts a lot sooner than you may expect. There is a huge difference between a $100 camera and a $1,000 camera but there is very little difference between a $1,000 camera and a $3,000 camera. You’ll want to stay at this sweet spot of about $1,000 for your camera. Maybe even lower if you’re on a serious budget. So, once you understand that you don’t need to drop $5,000 on your first camera let’s get right into the gear.

Camera
Your camera is going to be your workhorse, so leave a little more room on the budget for a solid camera. Since our main objective is video I’m going to focus on the two powerhouse brands in the video market right now: Panasonic and Sony. I’m not going to discuss which is the better camera, but Sony seems to run on the more expensive side compared to Panasonic’s line. I think the best budget friendly 4k camera on the market today is the Lumix G7 from Panasonic. It currently cost around $600 with the kit lens but I’ve seen them as low as $500 during sales. You get a ton of features for the price and you’ll be future proof for a bit longer with the 4k video resolution. If you do end up going the Sony route be aware that you’ll be paying a premium for lens’ and accessories.

Lens
Lenses are often overlooked when getting into videography; however, I believe having the right lens can be more important than having a high-end camera in most cases. You’ll want to keep a little money for a nice quality lens or two. Most kit lenses are sufficient, but having a couple focal lengths to choose from will definitely step up your quality game. I like to use a 25mm fixed (equivalent to a 50mm in full frame) and a 12–60mm zoom lens. The 25mm is one of the cheapest lenses out there and it is very versatile. The 12–60mm, or 14–42mm if you get the G7, will be a great ‘run & gun’ lens.

Audio
Sound is just as important as video and if you’re lacking in the sound department, no one will watch your videos. The brain actually processes sound before visuals so it is crucial to spend just as much, if not more time, perfecting audio than video. The on-board audio from your camera is garbage.  But you do have a few options as far as audio recording goes. If you’re not sure what kind of videos you’ll be making, I’d recommend going with a small shotgun mic that attaches to the camera’s shoe mount and plugs directly into the camera. Rode makes a nice line of mics for this category and the two big options are the VideoMic GO or the VideoMic Pro. The Pro version has a built-in audio processor while the GO version is just a shotgun microphone using the cameras audio processing. There is plenty of info out there comparing these mics so you’ll have to make the call on which one will fit your needs. Of course, in some cases a lavalier mic (worn on the collar) or external shotgun mic will work better but this is going to cost a lot more and won’t be as versatile.
Here are a few of my recommended microphones on the market:
VideoMic Pro - http://amzn.to/2i4KEg7
VideoMic GO -  http://amzn.to/2wOmI3Q 
Great wireless lavalier - http://amzn.to/2i38Pvg
Affordable lavalier - http://amzn.to/2vZKaxm
Solid external shotgun mic - http://amzn.to/2vGOAXB 

Lighting
You will go crazy trying to find the best lighting equipment on a budget so, to make this easy for you, just pick up some 700W softbox lights for $60 - $80. For most shoots, I like to use as much natural light as possible and I find myself rarely using artificial light. But it is great to have some as a backup just in case. Good lighting will take creativity and practice so don’t spend a ton of money on lighting early on.

Everything else

Tripod – Amazon basics makes an affordable tripod that gets the job done, however if you have more to spend I’d recommend the Manfrotto 290 Xtra as it is a much higher quality. You can watch my review if it here: https://youtu.be/U-0_l_zkncQ 
Manfrotto tripod - http://amzn.to/2vBRdv3
AmazonBasics tripod - http://amzn.to/2wOxLKq 

Batteries – Four batteries should be plenty for a day of shooting and you can find batteries for your camera relatively cheap from numerous brands on Amazon.

SD Cards – The one thing you’ll want to look out for here is the speed of the card. Make sure the card says U3 which is usually 95MB/s. Having two 64GB SD cards should give you just over 2hours of 4k recording.
95MB/s - http://amzn.to/2fIJJkJ
150MB/s - http://amzn.to/2vGXUL3

Storage – You’re going to go through hard drives like never before when you start importing all the 4k video files so make sure you set aside some money for external hard drives. If you’re getting paid to do video work you will need to back up everything at least twice. The last thing you want is a corrupt or failed hard drive with someone’s valuable footage on it so save yourself that headache and back it all up.

Editing software – This is mainly personal preference but you can’t go wrong with Adobe Premiere Pro CC which is available in the Adobe Creative Cloud service. Another good editing program is Sony Vegas but I haven’t used that brand nearly as much as Adobe’s programs. If you’re a student in college you can get a nice discount on the creative cloud membership and it’s well worth it.

Conclusion 
Remember this is the bare minimum of what you would need to start shooting professional videos. There are TONS of other accessories that would help you create the best possible product however it would also cost a lot more for all of it. You will more than likely end up like me - purchasing a new piece of gear for every new project, with some reason to justify your guilty spending. But in the end, it comes down to you as a creative videographer and your ability to create a meaningful story through the lens. If it all came down to who had the best equipment then all the richest filmmakers would have the best content and this is simply not the case. So do your research, buy a camera that fits your budget, and start filming.

But keep in mind - the best camera is always the one you have with you.


Everybody has heard of secret menu items at Disneyland, and almost every eatery has at least one.  So myself and some friends have started a living document to track and rate the secret menu items we run across.


Captive portals have become synonymous with guest Wi-Fi in enterprise environments. From Starbucks to your doctor's office people expect free and easy to use Wi-Fi,  but what was once easy to do is getting more difficult. Browser security is always improving which has made the goal of HTTPS redirects even more difficult. Captive portal redirection for users going to HTTPS websites has always created SSL related errors -- this has helped create a cry wolf scenario when it comes to HTTPS redirection errors. This error rich environment has helped HSTS errors fly under the radar.

At a high level HSTS (HTTP Strict Transport Security) is a policy that, when enabled, forces a browser to use an HTTPS connection over a HTTP and allows for the SSL certificate to be cached on the browser for a predetermined length of time. With HSTS enabled, clients are protected from protocol downgrading, man in the middle attacks, and cookie hijacking. Most modern browsers (Google Chrome, Mozilla Firefox, Microsoft Edge) come preloaded with a list of sites supporting STS (Strict Transport Security).  Along with the pre-configured list built into browsers, developers can take it upon themselves to enable this policy on their sites. Once enabled a timeout will be sent with the HTTPS header that contains a HSTS TTL Strict-Transport-Security: max-age=31536000”. The certificate received from the site will be honored until the timeout expires. Future attempts to access the site will reference the certificate and,  if the certificate does not match, the browser will not allow the connection to site to be established.

For a more in depth HSTS description check out Troy Hunt's post Understanding HSTS.

So how does HSTS break captive portals?  HSTS enforces the use of HTTPS. It enforces this using two methods that where mentioned earlier the HSTS header or STS preload lists in the browser. When a user connects to a captive portal and launches their browser, normally the wireless controller would intercept their Internet request and a redirect is sent back to the client. This redirect to the captive portal will obviously be a different CN than their original request so, many times, this creates an SSL error. Many users have become numb; accepting the error and continuing to the portal. But HSTS is a little different.


Because HSTS already knows the website should be using HTTPS the browser issues an internal HTTP 307 redirect redirecting the traffic to HTTPS even before it attempts to connect to the server. Once it connects to the server it attempts to validate the HSTS valid certificate. In the case of a redirection the captive portal would not be insuring the same HTTPS HSTS validated certificates. When this happens the browser will assume something nefarious is going on and not allow the redirection to occur. I know one vendor has a bug report filed for this issue - even though its not really a bug - and I don't know if its a fix the wireless vendors can provide.

Bottom line for users connected to a captive portal today:
  • If the user visits an HTTP site, they are immediately redirected to the captive portal. This works regardless of what browser they are using
  • If the user visits an HTTPS site that does not use HSTS, they receive a warning. If they click "Continue" they are redirected to the captive portal. This works regardless of browser
  • If the user visits an HTTPS site that does use HSTS and they are using the browser that supports HSTS they are dead-ended. The only way to get redirected to the captive portal is to visit a different site. Many people have https://www.google.com or Facebook set as their homepage. Both of these sites use HSTS so this might confuse some users.

This issue of not being redirected to a captive portal affects every wireless vendor. As more and more sites use HSTS, getting a proper redirect becomes harder. Hopefully the wireless vendors are sitting on the working group for this new standard and are pushing hard to get it ratified. 

In the long run, if something is not done, enterprises will quit using captive portals if it becomes really tough to get a proper redirect. But for now, being forced to use captive portals, I have not seen a sure fire technical way of getting around the issue.  But you can get around the HSTS errors through communication and policy. 

For example:
I am considering turning off HTTPS redirection all together. What this does is create a predictable environment for the users and the system admins. By not redirecting HTTPS you take the confusion of redirection issues based on SSL certificates, HSTS, or any new security the browsers builds in and level the playing field. Then in the case of using a sponsored portal, the email notification that is sent to visitor and/or person being visited can include the verbiage, "If you are not redirected to the guest portal please type a non secured HTTP website into your browser".