APM (& LTM) Session & Cookie Information - Chrome Extension
Problem this snippet solves: If you've ever troubleshooted APM Portal Access issues, you know how annoying it can be to find the decoded internal url. Note: This extension has been updated as more of an APM and LTM extension as opposed to just an APM one. This chrome extension seeks to make that quick and easy by showing the decoded information. It will also display the cookies for that site (including the ever-useful MRHSession and LastMRH_Session cookies) and allows you to delete cookies directly from the extension (useful for testing session timeout if you delete the MRHSession cookie). Version History 1.1 - Initial version Includes APM portal access decoded url information 1.2 - 2016.04.01 Added list of cookies associated with the current site (shows cookie name, domain and value) 1.3 - 2016.04.25 Added ability to delete cookies from the extension for the site (Known Issue: if you have multiple cookies with the same name that match the page, deleting one will delete all of them) Added decoded BIG-IP persistence cookie value in parenthesis to the list for quicker reference 1.4 - 2016.06.30 Rebuilt the popup page using AngularJS Introduced (but still disabled) options page and client-side functionality (will need iRules development as well) 1.5 - 2016.09.07 Enabled the options page again, and finished code to allow the extension to add a header to requests on specific domains (user specified) 1.5.1 - 2016.09.18 Updated the icon, and removed APM and replaced with debugging icon since this has morphed to APM and LTM usefulness 1.6 - 2016.12.19 Now enables the extension when it determines a persistence cookie (based on value format) Added a link that will popup APM session details (when management url specified in options page) (Note: must be logged into the management GUI already or else it won't redirect properly). Used alongside my APM Tampermonkey script you can see the session variables as well as the session detail 1.7 - 2017.09.03 Added local tracking of sites that appear to use F5 BigIP How to use this snippet: As Chrome doesn't really like unpublished extensions, and it's not in the Chrome App Store (yet), you'll have to install the extension in Developer Mode. Instructions Navigate to chrome://extensions Ensure that the Developer mode checkbox is enabled Sub-Method 1: Load unpacked extension (preferred method) Download all the code from the Github repository Click the Load unpacked extension button and select the src folder Sub-Method 2: Load the crx file (may not always be current) Download the crx from the Github repository From the file system, click and drag the .crx file onto the extension page to install it Code : https://github.com/jangins101/F5-APM-Session-Information Tested this on version: 11.5
Security Sidebar: Google Leads The Way On Sunsetting SHA-1
SHA-1 (or Secure Hash Algorithm) is a cryptographic algorithm that was developed by the National Security Agency in the 1990s and is widely used in popular cryptographic protocols like Secure Sockets Layer (SSL) and Transport Layer Security (TLS). These protocols are designed to provide secure communications over the Internet. The SHA-1 algorithm is commonly used by Certificate Authorities (CA) as a part of the overall Public Key Infrastructure (PKI). While the intent of this article is not meant to fully explain PKI, it is important to note that many CAs utilize the SHA-1 algorithm to digitally sign certificates for secure websites. These CA-issued certificates are critical for users who want to maintain a level of trust and security when accessing those secure websites. If a user visits a secure website (https) and the digital certificate is not valid, it could mean that a bad guy is attempting to steal your information. Your Internet browser (Internet Explorer, Firefox, Chrome, Safari, etc) will notice that the certificate is bad and it will alert you to the fact that you are about to engage in some non-secure communications. Each browser presents this information in a slightly different way, but they all give you an alert nonetheless. The screenshot below shows an example of Google Chrome attempting to access a secure website that has an invalid certificate. On September 5, 2014, Google announced that their popular Chrome browser will sunset the SHA-1 algorithm. They claim that SHA-1 has been a weak digital signature algorithm for at least 9 years. One of the primary reasons for this weakness is the ease of collision attacks against SHA-1, thus prompting Google to declare it no longer safe for public consumption. Google is not alone in their current fear and loathing of SHA-1...most other browsers have stated their intention to deprecate SHA-1 as well. While everyone agrees that SHA-1 needs to be replaced, not everyone agrees on the process or timeline to do so. Starting in November 2014 (as in, like, next month), Google will methodically sunset the SHA-1 algorithm starting with Chrome version 39. Websites using HTTPS whose certificate chains use SHA-1 and are valid past January 1, 2017 will no longer appear to be fully trusted in Chrome. Google Chrome has several different icon indicators in the address bar that display the overall trust factor of a given certificate chain for the website you are accessing. The first is a lock with a yellow triangle over it. This indicates a certificate chain that is "secure, but with minor errors." The next is a blank page icon. This indicates a certificate chain that is "neutral, lacking security." The last is a lock with a red X and a red strike-through text treatment in the URL scheme. This indicates a certificate chain that is "affirmatively insecure." Check out the above screenshot again...notice that it falls in the category of "affirmatively insecure" based on the red X and the red strike-through text in the URL. So, how does all this fit together? Well, Google has announced that it will start displaying these various icons on websites that use the SHA-1 algorithm. The following table shows the details of the SHA-1 certificate expiration date and the related Chrome icon display in the address bar. Today, SHA-1 is used in over 98% of certificates issued worldwide. Likewise, Google Chrome accounts for 38% of all Internet browsers used today (as of August 2014...see the chart below). When you combine the fact that Google Chrome accounts for almost 40% of all Internet browsers and SHA-1 is used in over 98% of all certificates worldwide, you can see why so many CAs are scrambling right now to re-issue new certificates in very short order. As you update/validate the certificates in your organization, you will need to verify that legacy applications will support the new algorithm. Also, if you have external hosted applications, you may need to issue new certificates so that users don't get those crazy browser warnings. This SHA-1 situation is just another reminder of the ever-changing technical world we live in. It's important to know what's out there, and it's important to stay as much ahead of it as possible.
F5 Chrome plugin (extension) disabled after Google Web Store change
Hi, I have the F5 Networks Plugin Host (v 7091.2013.1211.1151) installed in Chrome which I downloaded from F5 for work. Today, the extension is disabled by Google because it did not come from the Web Store. I did a search of the Chrome Web Store and I don't see the plugin there - are there any plans to release the plugin on the Web Store so it can work with Chrome again? Thks, JFG
DevCentral access using Chrome - The requested URL was rejected. Please consult with your administrator.
Hello all, Is anyone else having trouble accessing DevCentral? I use Chrome as my main browser which used to be fine - but from probably 4 or 5 weeks ago - whenever I try to access any DevCentral URL - eg: https://devcentral.f5.com/Default.aspx?tabid=63&articleType=ArticleView&articleId=285 ...I get this message: The requested URL was rejected. Please consult with your administrator. Your support ID is: 14079010617147482426 Searching on here says that's an ASM message - but since this is an F5 hosted site - that's F5's ASM I'm guessing? Don't know much about ASM - why would it be blocking access from Chrome only? Same URL works fine with IE or Firefox from the same laptop. I can't see any other notes on here about this so I'm guessing it isn't everyone with Chrome? Any ideas?Searching DevCentral Just Got Easier
I recently received an internal iRule email and one of our folks created a search provider for FireFox to search DevCentral. Lori quickly responded and asked if we could get this posted to DevCentral. Why not if it will help the community so I took a look. Then it occurred to me that a while back I created a search provider definition based on the OpenSearch specification. For some reason, on our last site refresh, the links in our website were removed so the browser didn’t natively pick them up. I fixed that so now you can add DevCentral as a native search target in your browser of choice. Here’s a little background on OpenSearch, how I implemented it on DevCentral, and how to set it up in your browser. OpenSearch OpenSearch is a format that can be used to describe a search engine so that it can be accessed and used by search client applications such as web browsers. It’s basically just an XML file that you put on your webserver and by adding a hidden tag in your application pages, a browser is able to automatically access the search pages on your site. Creating the Search Engine The first step is to create the search engine definition file. In this case, I called that file OpenSearch.xml. The format for that file is defined here. For DevCentral, you can view the definition directly at OpenSearch.xml.
A Billion More Laughs: The JavaScript hack that acts like an XML attack
Don is off in Lowell working on a project with our ARX folks so I was working late last night (finishing my daily read of the Internet) and ended up reading Scott Hanselman's discussion of threads versus processes in Chrome and IE8. It was a great read, if you like that kind of thing (I do), and it does a great job of digging into some of the RAMifications (pun intended) of the new programmatic models for both browsers. But this isn't about processes or threads, it's about an interesting comment that caught my eye: This will make IE8 Beta 2 unresponsive .. t = document.getElementById("test"); while(true) { t.innerHTML += "a"; } What really grabbed my attention is that this little snippet of code is so eerily similar to the XML "Billion Laughs" exploit, in which an entity is expanded recursively for, well, forever and essentially causes a DoS attack on whatever system (browser, server) was attempting to parse the document. What makes scripts like this scary is that many forums and blogs that are less vehement about disallowing HTML and script can be easily exploited by a code snippet like this, which could cause the browser of all users viewing the infected post to essentially "lock up". This is one of the reasons why IE8 and Chrome moved to a more segregated tabbed model, with each tab basically its own process rather than a thread - to prevent corruption in one from affecting others. But given the comment this doesn't seem to be the case with IE8 (there's no indication Chrome was tested with this code, so whether it handles the situation or not is still to be discovered). This is likely because it's not a corruption, it's valid JavaScript. It just happens to be consuming large quantities of memory very quickly and not giving the other processes in other tabs in IE8 a chance to execute. The reason the JavaScript version was so intriguing was that it's nearly impossible to stop. The XML version can be easily detected and prevented by an XML firewall and most modern XML parsers can be configured to stop parsing and thus prevent the document from wreaking havoc on a system. But this JavaScript version is much more difficult to detect and thus prevent because it's code and thus not confined to a specific format with specific syntactical attributes. I can think of about 20 different versions of this script - all valid and all of them different enough to make pattern matching or regular expressions useless for detection. And I'm no evil genius, so you can bet there are many more. The best option for addressing this problem? Disable scripts. The conundrum is that disabling scripts can cause many, many sites to become unusable because they are taking advantage of AJAX functionality, which requires...yup, scripts. You can certainly enable scripts only on specific sites you trust (which is likely what most security folks would suggest should be default behavior anyway) but that's a PITA and the very users we're trying to protect aren't likely to take the time to do this - or even understand why it's necessary. With the increasing dependence upon scripting to provide functionality for RIAs (Rich Interactive Applications) we're going to have to figure out how to address this problem, and address it soon. Eliminating scripting is not an option, and a default deny policy (essentially whitelisting) is unrealistic. Perhaps it's time for signed scripts to make a comeback.Is the URL headed for the endangered technology list?
Jeremiah Owyang, Senior Analyst, Social Computing, Forrester Research, tweeted recently on the subject of Chrome, Google's new open source browser. Jeremiah postulates: Chrome is a nod to the future, the address bar is really a search bar. URLs will be an anachronism. That's an interesting prediction, predicated on the ability of a browser translate search terms into destinations on the Internet. Farfetched? Not at all. After all, there already exists a layer of obfuscation between a URL and an Internet destination; one that translates host names into IP addresses, hiding the complexity and difficult in remembering IP addresses from the end-user. And apparently Chrome is already well on its way to sending URLs the way of the dodo bird, otherwise we wouldn't be having this conversation. But IP addresses, though obfuscated and hidden from view for most folks, aren't an anachronism any more than the engine of car. Its complexity, too, is hidden from view and concern for most folks. We don't need to know how the engine gets started, just that turning the key will get it started. In similar fashion, most folks don't need to know how clicking on a particular URL gets them to the right place, they just need to know to click on it. Operating technology doesn't necessarily require understanding of how it works, and the layer of abstraction we place atop technology to make it usable by the majority doesn't necessarily make the underlying technology an anachronism, although in this case Jeremiah may be right - at least from the view point that using URLs as a navigation mechanism may become an anachronism. URLs will still be necessary, they are a part of the foundation of how the web works. But IP addresses are also necessary, and so is the technology that bridges the gap between IP addresses and host names, namely DNS. More interesting, I think, is that Jeremiah is looking into his crystal ball and seeing the first stages of Web 3.0, where context and content is the primary vehicle that drives your journey through the web rather than a list of hyperlinks. Where SEO is king, and owning a keyword will be as important, if not more so, than brand. The move to a semantic web necessarily eliminates the importance of URLs as a visible manifestation, but not as the foundational building blocks of how that web is tied together. To be fair to other browsers, the address bar in FireFox 3 also acts like a search bar. If I type in my name, it automatically suggests several sites tied to my identity, and takes me by default to this blog. Similarly a simple search for "big-ip" automatically takes me to F5's product page on BIG-IP. That's because my default search engine is Google, and it's taking me to the first ranked page for the search results. This isn't Web 3.0, not yet, but it's one of the first visible manifestations we have of what the web will eventually become. That's what I mean about keywords becoming the new brand. Just as "bandaid", which is really a brand name, became a term used to describe all bandages, the opposite will happen - and quickly - in a semantic web where keywords and phrases are automatically translated into URLs. SEO today understands the importance of search terms and keywords, but it's largely a supporting cog in a much larger wheel of marketing efforts. That won't be true when search really is king, rather than just the crown prince. But URLs will still be necessary. After all, the technology that ties keywords and search terms to URLs requires that URLs exist in the first place, and once you get to a site you still have to navigate it. So while I'm not convinced that URLs will become a complete anachronism, they may very well become virtualized. Just like everything else today.
