Disable HTTP2 profile from iRule?
Hi! We will implement HTTP2 since it's supported in version 12. There is one iRule assigned to VIP that requires SSL renegotiation. Renegotiation conflicts with HTTP2 and gives SPDY protocol error. This iRule asks for a client certificate from card reader for a specific URL and country. It's easy to select another SSL profile with renegotiation enabled for this specific country, but it would be better to use another SSL profile for this specific URI only. HTTP URI is not allowed within CLIENT_ACCEPTED, but we can live with disabling HTTP2 for a country if there is no way to accomplish this. The most important is to figure out how to disable HTTP2 profile on the VIP for this URL or country. I have not yet found a solution for this. WAM::disable is not working. Any help is highly appreciated because this is a blocker now for enabling HTTP2. iRule: Initialize the variables on new client tcp session. when CLIENT_ACCEPTED { set collecting 0 set renegtried 0 Find out country tag set CountryID "[whereis [IP::client_addr] country]" Use SSL profile with renegotiation enabled if {$CountryID eq "EE"} { SSL::profile with_renegitiation_enabled } } Runs for each new http request when HTTP_REQUEST { /player/identification/eid/start triggers client cert renegotiation if { $renegtried == 0 and [SSL::cert count] == 0 and (([HTTP::uri] starts_with "/player/identification/eid/start") || ([HTTP::uri] starts_with "/player/authentication/authentication/loginEid")) } { Collecting means buffering the request. The collection goes on until SSL::renegotiate occurs, which happens after the HTTP request has been received. The maximum data buffered by collect is 1-4 MB. WAM::disable HTTP::collect set collecting 1 SSL::cert mode request SSL::renegotiate } } After a handshake, we log that we have tried it. This is to prevent constant attempts to renegotiate the SSL session. I'm not sure of this feature; this may in fact be a mistake, but we can change it at any time. It is transparent if we do: the connections only work slower. It would, however, make BigIP detect inserted smartcards immediately. Right answer depends on the way the feature is used by applications. when CLIENTSSL_HANDSHAKE { if { $collecting == 1 } { set renegtried 1 Release allows the request processing to occur normally from this point forwards. The next event to fire is HTTP_REQUEST_SEND. HTTP::release } } Inject headers based on earlier renegotiations, if any. when HTTP_REQUEST_SEND { clientside { Security: reject any user-submitted headers by our magic names. HTTP::header remove "ID-EE-SSL_CLIENT_CERTIFICATE" HTTP::header remove "ID-EE-SSL_CLIENT_CERTIFICATE_FAILED" if certificate is available, send it. Otherwise, send a header indicating a failure, if we have already attempted a renegotiate. if { [SSL::cert count] > 0 } { log local0. "Client Certificate: [X509::subject [SSL::cert 0]]" HTTP::header insert "ID-EE-SSL_CLIENT_CERTIFICATE" [X509::whole [SSL::cert 0]] } elseif { $renegtried == 1 } { This header has some debug value: if the FAILED header is not present, BigIP is probably not configured to do client certs at all. HTTP::header insert "ID-EE-SSL_CLIENT_CERTIFICATE_FAILED" "true" } } }
HTTP/2 and Request Logging
On our BIG-IP (Version 12.1.2 Build 0.93.249) we tried adding HTTP/2 Profile to one vServer. The Browser answered with "ERR_CONTENT_DECODING_FAILED". After some troubleshooting, we identified the "Request Logging Profil" as the main cause. After reading this article I tend to accept that the high speed logging (hsl) writes variables before the HTTP_Request event and therefore can't handle the HTTP/2 Stream. Is the only way to log requests while using HTTP/2 via an iRule or is this issue fixed in later BIG IP Versions?
Why think about HTTP 2.0?
#webperf #HTTP #mobile The problem with web application performance is directly related to the increasing page size and number of objects comprising pages today. Increasing corporate bandwidth (the pipe between the Internet and the organization) doesn't generally help. The law of diminishing returns is at work; at some point more bandwidth (like more hardware) just isn't enough because the problem isn't in how fast bits are traveling, but how many times bits are traversing the network. And for some clients - like mobile - it doesn't matter. They're getting 1-4Mbps and there's nothing you can do to change that. The problem is HTTP isn't utilizing TCP efficiently, and thus the round trip - the time it takes for clients to talk to the application - is almost always the real culprit when looking for the source of web application performance issues. Especially for mobile clients, where a round trip carries with it an average latency of 150-300 ms. More efficient use of TCP, better connection management, compression and other acceleration techniques are a must if we're going to really address web application performance. And that's what HTTP 2.0 is designed to do.
An Approach to Future-Proofing
How to design applications for scale, efficiency, and change. In the IT industry, we have become immune to messages of change. But we are counting on technology to fuel the next waves of growth. This forces technology leaders to think about new operating models to enable growth, profitability, and agility. It’s imperative that IT bring to the table options that will lower cost and add business value by a deep understanding of new technology. The key to responding quickly to industry changes and dynamic customer needs will be solutions that are future-proof– designed to quickly and effectively respond to change. Companies can respond quicker by shifting from a silo approach to a fabric approach. F5’s services fabric model enables consolidation of services onto a common platform that can be deployed on hardware, software or in the cloud, reducing operational overhead by standardizing. With a fabric model comes a future friendly design that is able adapt to new technology without touching each application or server. New innovations, technologies and standards are emerging. High performing organizations track them and leverage them as soon as possible. For example, the IETF is scheduled to release HTTP 2.0 later this year, with the goal to deliver a faster web. Today’s web is built with modern applications that consume more bandwidth and is more complex. Latency and blocking are notorious for causing slow page loads giving users a poor experience. With BIG-IP v11.6, F5 is the only ADC vendor to support HTTP 2.0 gateway (built to the draft standard) and SPDY 3.1 gateway. By utilizing HTTP 2.0 thru F5, organizations can reduces page load times by up to 50% by minimizing protocol overhead and making multiple parallel requests to overcome unnecessary latency and blocking to different web servers like Apache or IIS. HTTP 2.0 and SPDY switches to an encrypted SSL connection by default to protect data. Unfortunately, as applications default to SSL, IT becomes increasingly blind to their outbound application traffic making it difficult to manage. F5 enables SSL visibility and control to give businesses the power to eliminate blind spots and protect investments in existing security infrastructure. The SSL key lifecycle is easily managed and protected with policy enforcement for operational efficiency. The technologies that power modern web applications are very different today. To build a future-proof architecture it’s important to take advantage of the technology to adapt to the changes in modern applications -- whether in your own data center or in the cloud. You need a design that meets the needs of your users, not just today, but can also evolve to support the future.F5 Synthesis: Hybrid to the Core
#SDAS #SDN #Cloud #SSL #HTTP2.0 F5 continues to pave the way for business to adopt disruptive technologies without, well, as much disruption. The term hybrid is somewhat misleading. In the original sense of the word, it means to bring together two disparate "things" that result in some single new "thing". But technology has adapted the meaning of the word to really mean the bridging of two different technological models. For example, a hybrid cloud isn't really smashing up two cloud environments to form a single, new cloud, rather it's bridging the two technologies in a seamless way so as to make them interoperate and cooperate as if they were a single, unified cloud. This concept is necessary because the way in which data center and computing models evolve. We don't ditch the last generation when the next generation comes along. Rather we graft the new onto the old or combine them in ways that enable the use of both - albeit often times separately. IPv4 and IPv6, for example, pose significant challenges due to incompatibilities. The reliance on the former and the need for the latter drive us to adopt technology such as gateways and brokers to enable a smooth(er) transition from the old to the new. Hybrid is a way to keep organizations moving forward, without sacrificing support for where we are right now. As organizations are challenged to adopt the latest applications and technology based on cutting-edge protocols to improve performance and gain advantages through efficiency, they are simultaneously challenged to scale network infrastructure to handle more traffic, more applications and more "things" connecting to their networks. Cloud offers a path forward, but introduces challenges, too, in managing access, performance, security and scale across an increasingly distributed set of domains. Organizations need hybrid answers to hybrid challenges that threaten the reliability and security of their applications. F5: Hybrid to the Core F5 is no strange to providing hybrid answers to hybrid challenges. F5 Synthesis Software Defined Application Services (SDAS) provide a robust set of services spanning protocol and application layer gateway capabilities that mean you can support a hybrid cloud as easily as a hybrid network that incorporates SDN or emerging protocols like HTTP 2.0. With the release of BIG-IP 11.6 - the platform from which F5 Synthesis High Performance Services Fabric is composed - organizations will be even better positioned to take advantage of new and existing technologies simultaneously while meeting hyperscale challenges arising from even more devices and more applications in need of services. F5 is the first and only vendor to support HTTP 2.0 with BIG-IP 11.6. Like IPv6, HTTP 2.0 is incompatible with the existing de facto standard version (1.1), making it difficult for organizations to move forward and enjoy the proffered benefits of HTTP 2.0 in faster, simpler and more secure applications. F5's approach is hybrid: why be constrained to just one version when you can support both? Too, why must you choose between the performance benefits of hardware-accelerated SSL or the flexibility of a virtual ADC on off-the-shelf hardware? F5 believes you shouldn't have to, and offers another first in the industry - a hybrid SSL offload approach. Organizations can enable 8 times the SSL capacity by taking advantage of the hybrid nature of the F5 High Performance Service Fabric enabled through its unique ScaleN technology. And then, of course, there's cloud and the Internet of Things (or BYOD if you're still focusing just on devices) driving the need for a different kind of access control strategy; a hybrid one. Whether it's things or people, traditional access control techniques that rely on IP address and can't effectively manage both cloud and data center deployed applications isn't going to cut it. Add in the need to hyperscale to meet demand and you need a more hybrid-friendly approach. BIG-IP 11.6 puts the focus on identity-based firewalling into our application delivery firewall services. Combined with existing cloud-identity federation capabilities based on broad SAML support, a seamless hybrid cloud experience for SSO and access is well within reach. As F5 continues to expand and extend the capabilities of its Software-Defined Application Services (SDAS), the notion of "hybrid" architectures, technologies and networks will remain core to its capabilities to ensure organizations can continue to deploy and deliver applications without constraints.SSL gets an SEO promotion in rank from Google. Business loses its mind.
#SSL Forget #infosec benefits and #webperf implications, SSL just did an end-run around IT and went straight to the business. With fewer than 1/3 of organizations securing apps with SSL, that could be a problem. If the business isn't panicking, it should be. Google is taking a stand on security, and using the power of placement to get the word out: SSL is important. Given that fewer than one-third of all web apps are secured with SSL despite its benefits, strong-arm business tactics may be just what the security doctor ordered. Google is taking a stance on security and has made SSL a piece of their ranking algorithm. As we are aware search engine ranking remains one of the single most important components of any organization’s branding efforts and online presence. -- HTTPS as a ranking signal, August 6, 2014 in its announcement regarding the inclusion of SSL (or TLS) in its ranking algorithms, Google also noted some best practices to get folks started in their journey to a more secure web presence. Most focus on the strength of the certificate keys you should use (2048 at least) and app development tips that can make the transition between HTTP and HTTPS less disruptive, such as using relative URLs. But even so, what isn't mentioned is the administrative nightmare imposed by turning on SSL (or TLS) on every app server in the data center. It's not just the short term go out and get them (which aren't cheap, by the way) and get them deployed, it's also the impact long term on managing expirations as well as figuring out how all the services in the network between the end-user and the app - like that IDS and IPS, your anti-virus and anti-fraud, your WAF, etc... - are going to perform their tasks blindly. Without a solid strategy moving forward, simply turning on SSL on an application disrupts not only operations but a whole lot of security and business-related services. One of the ways in which this journey can be made much less disruptive is by taking advantage of strategic transition points along an application's data path where SSL can be applied (and thus also managed) centrally. This point logically occurs at the point at which the application is virtualized for purposes of scale and reliability. In other words, at the load balancer or application delivery controller (ADC). By using an ADC or an application proxy as a natural protocol gateway (something that can transition easily between two protocols like HTTP and HTTPS, or vice versa) the disruption of enabling SSL everywhere (which is a Very Good Thing TM by the way) on every app server can be effectively eliminated. The reality is that your load balancer (LB) or ADC or application proxy (AP) is, for all intents and purposes, The Application as far as the end-user is concerned. It is at the LB or ADC or AP that an application is "virtualized" and presented to the outside world. When an end-user connects to www.myapp.com they are almost certainly connecting not to the app, but to a load balancing service or an ADC or an application proxy. This provides a strategic opportunity for organizations to centralize capabilities like enabling SSL or supporting next-generation protocols like SPDY or HTTP 2.0 without incurring the costs and headaches associated with upgrading and updating each and every one of the hundreds (or thousands) of servers that provide the resources for that application. But the argument is no longer going to be focused on the technical merits or even the security benefits. The SSL argument has just gone business, because search engine ranking is a significant component of today's business. With SSL part of that ranking equation, the business is going to see competitive advantage in getting "out there" first with SSL to help boost their search rankings before their competitors. IT can be the hero this time by using a strategic point of control to get it done, and get it done fast. That means you're going to need a game plan, and you're going to need it sooner rather than later.
