What will HTTP/2 mean for DLP?

Does anybody have a good write-up on what the upgrade to HTTP/2 (with it's by-default HTTPS, compression and caching, always-on single connection) mean in context of Data Loss Prevention and information security considerations in general?

Thanks in advance. Doing some research for general education on the topic and wondering if something publicly available has already been done, so I don't have to reinvent the wheel here.
Oleksiy GaydaAsked:
Who is Participating?

[Product update] Infrastructure Analysis Tool is now available with Business Accounts.Learn More

I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

btanExec ConsultantCommented:
HTTP/2 is pretty new still ... though supposedly it has already been released for some time (back in mid-Feb15), there is yet to be a big adoption on this unless we see a shift on browser support into SPDY (which is also what HTTP/2 is based on). The main catch for adoption will really be its optimised and fast protocol compared to its legacy peer version...

However, that also may becomes security challenging to defend in area of DLP. The latter requires keyword, context indicator, tagging or marker, watermarking and rights embedded in document or meta-data for the DLP agent and server or sensors at perimeter to check inline and real time stop it from flowing out (Or sometimes even coming in from cloud or afraid to getting copyrighted items unintentionally "planted" thru..). This forms the basis on how we can take a snapshot of HTTP/2 "new way" of being speedy and rethink how it impact security defends of DLP

I am just taking below as snapshot and likely there is more to add and drill into as it becomes more "common"..

- HTTP/2 implement secure compression (uses header compression to reduce overhead)
> Implication - DLP cannot inspect unless they are protocol aware of this but with secure it is obviously protected. So how to inspect if you cannot see it in plain...?

- HTTP/2 allows servers to “push” responses proactively into client caches
> Implication - DLP will see surges of connection initiated from internal to external, so can DLP performance cope with this having to be inline and be real time stopping all concurrent connection and session, matching identity and perform context inspection using those meta-data data...looks like more CPU and memory resource to beef it up before we say DLP is ineffective ...or becomes a bottleneck for the security infrastructure.
> Implication (cont...) - Likely caching will trigger false positive unless there are TTL enforced to be short lived, furthermore, sensitive info should not be cached. By default, HTTP/2 seems to go for caching hence likely DLP have to re-sync the baseline via purging always or time-based...on what is good (can be non-sensitive) and bad many (many sensitive) to make no intentional store of long cache but it up the need for another task, another performance catch up and not overly security tedious operationally.

- HTTP/2 is fully multiplexed, instead of ordered and blocking
> Implication - DLP facing the above challenges shared, the multiplexed channel further "dissect" the puzzle piece into smaller pieces for DLP to piece out the actual keyword they are looking at. Yet another non-trivial hurdle to get over. Assembling and disassembling need to be drill into DLP for this protocol, being protocol-aware may not be sufficiently support its inspection needs. It may need to be protocol-intelligence besides being savvy - know how to "assemble" in the quickest manner not missing out any details unintentionally to balance DLP from getting high false positives...

- HTTP/2 uses one connection for parallelism
 > Implication - DLP should see this positively since lesser "lane" to check as a Custom bouncer doing the inspection. However, do not downplay this as single channel also means multiple streams concurrently running - imagine a chain accident crash over and even the Custom's roadblock need to make sure it can withstand not one car but multiple cars chained due to gate crashes unknowingly - inspection takes too long and queue form to "stress" out the DLP's checker and bouncer role...

- HTTP/2 is binary, instead of textual
> Implication - DLP will have to unscramble adn be intelligence besides being savvy on the protocol as I shared in previous pointers. Security via obscurity is still a lower hurdle that DLP has to overcome (jump over) though it is not tough compared to a high wall erected like it is encrypted...

- HTTP/2 is not TLS mandatory and prefers AEAD modes like GCM.
> Implication - DLP simply will not be able to inspect if this is make mandatory and not talk about the stronger encryption used in AEAD  compared to just AES (CBC/ECB etc weaker chaining used). Also even though Google and Mozilla say they are intending to support this TLS as mandatory, it should not be surprising eventually it will become a normal and SSL interception and decryption will likely push DLP solution to become its native support and preferably in same box or dedicated hardware card embedded rather then separate box or selective turn on or off

... Privacy asides, this still needs to be relook for DLP as a whole in how its future technology advancement...

(Pardon me for the lengthy write up).. Just some few cents worth..
For info on its FAQ @ https://http2.github.io/faq/

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
Scott Fell, EE MVEDeveloper & EE ModeratorCommented:
What encrypted connection means for DLP?
btanExec ConsultantCommented:
DLP also need to inspect even if encrypted tunnel like SSL etc is common via HTTP hence for DLP deployment, SSL decryptor are in placed at normally work together with web gateway on that...my few cents
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Network Security

From novice to tech pro — start learning today.