Headers, Caching, and Cookies: Oh my!

I had to pound my fists on the table again when the topic of cookies, caching, headers, and all sorts of jargon popped up when talking about the tech of webapps.  Webapps, like online shopping cart apps, are one of those concepts that are simple on paper but can easily become convoluted, especially when terms get swapped around or poorly defined.  So I'm running down the list based on experience.

Since this is pragmatist approach, not theoretical smoke & mirrors, I'll freely refer to common software implementations of the concepts, including Apache HTTPD, JBoss/Wildfly, and the all powerful cURL.

Back to Terms & Definitions

Back to basics.  Web services are almost entirely based on a protocol that was purposely designed to NOT maintain the state of any communication.  aka. HTTP.  "It is a generic, stateless, protocol"[1].   Technologists have, since the original inception, extended and modified HTTP to enabled stateful mechanisms. :sigh:  Those modifications include:

• Stickiness - "stickiness" is nothing more than than an antonym for "load balancing".  In other words, you actually _want_ your web client to be serviced by a particular server (affinity).  Implementations of stickiness are often done with HTTP Headers!  :gasp:  Not especially what they were intended for (see Web definition) but implementations in Header include:
• Cookie - statefulness; https://tools.ietf.org/html/rfc6265
• Sessions / SESSIONID (JSESSIONID/PHPSESSIONID) - more statefulness
• jvmRoute - mod_jk / mod_proxy[2]  

• Authenticated Sessions - obviously not the same as a bare bones web session; anyone who tells you that all you need is to put everything, including sessions, behind HTTPS is full of security blackmail.  TLS/SSL over HTTP has nothing to do with authenticating the session; it may (though not always) be authenticating the communication from client to server -- but that is it!  An Authenticated Session is not achieved by HTTPS.

• Caches - not to be confused with Cookies; client-side (web browser) cache[3] -- often mislabelled as "cookies"; server-side (web site) cache -- mod_cache
• Cache everything!  Actual web services payload may vary.  Based on data from one of the largest content delivery services for the Web, Akamai, the top 3 culprits slowing down web payloads are: 1) images, 2) images, and 3) images.

• Load balancing - only makes sense when talking about volume (throughput); has no bounded direct link to latency!  You can have a well balanced load that includes a session that is simply slllllooooww (latent).  That in no way means the lb (mod_proxy, mod_cluster for Apache HTTPD) is broken but could very well mean a stuck thread on the backend JBoss or DB.

References

[1] https://tools.ietf.org/html/rfc2616. versus  https://tools.ietf.org/html/rfc6265
[2] http://tomcat.apache.org/connectors-doc/reference/workers.html
[3] pg. 108 / Section 14.9 Cache-Control, https://tools.ietf.org/html/rfc2616#section-14.9

Security: Smartphones v PC: Deja vu

My officemate's smartphone was stolen.  By the time she got online via her laptop (because she was nowhere near home), the remote lock or wipe couldn't find her phone.  It had been stolen/wiped.  

Smartphone security paranoia popped up again in conversation when a friend overlooked my shoulder and saw how ridiculously long it took me to type my password.  He quipped:

"You know that's not secure".
I said, "I've encrypted the phone."
"Oh I can get around that", he said.
"You mean the USB connection and an Android debugger?  Yes I suppose you could eventually brute force it but that will take awhile.  By then, I'll remotely wipe the phone."

My hope was to avoid a debate about fundamental problems with IT security, and share my belief that a simple risk/reward exercise (including the annoyance of securing a tech device versus its usability), should result in enough security to give hackers at least a big headache if not full on despair.  My belief about consumer electronics security is: hackers with a specific vendetta against YOU personally -- so someone wanting to ruin your life -- will invest considerable effort in tearing down layers of security; versus hackers at large looking to exploit maximum reward with minimum effort by targetting smartphones/PCs/etc en masse will skip over consumers with decent layers of security.  In other words, most folks have more to fear from their closest friends and family -- who already have access to private or personal information about you anyways -- than anonymous hackers who only know you as an IP address, but only IF you've dotted your i's and crossed your t's.

So smartphone security should target two camps:

1. local / physical access
2. remote access

Assume an ex stalks you online, goes covert to get a job as a repairman so she gets access to the building you work at, secretly stalks you at work to figure out when you occasionally leave your smartphone on your desk --, and nabs your phone while you're in the bathroom.  OK now your ex has local / physical access to your smartphone.  Only a few common security "states" exist for any smartphone:

• unlocked screen
• locked screen
• connected phone
• disconnected phone

The interesting thing to notice about this list smartphone states is they apply to computers generally, especially the old PC from yesteryear.  Desktops, laptops, smartphones, etc. consumer technologies have many security traits in common, and this commonality means that basic security concerns for computer technology in general applies to smartphones specifically.  A PC from 20 years ago, this list for solutions were:

screensaver w/ password

disconnected PC (no LAN)
encrypted disk

20 years ago, it was silly to leave a computer screen unlocked, and trivial to get data from the computer if its disks were not encrypted and someone, like your ex, still had physical access to your PC.  The same applies to smartphones today.  

My friend's theory was a hacker just inserts a USB cable to bypass a smartphone password.  Google Android smartphones have had local storage encryption since 2011, and Apple iPhones have had local storage encryption since 2009, so both major smartphone manufacturers finally caught up to Blackberry RIM (which had been encrypting smartphones since insert date to close that security hole.  (One technical point: Android still does not encrypt external or expandable storage --  SDCards or any storage media that is not primary storage -- but Blackberry's later OSes did encrypt removable storage media.  Another point of digression: Blackberry smartphones so were highly regarded for their security than some governments outlawed their sale or used their own intelligence agencies against Blackberry's secure communications, such as India.)

Seeing the same risk profiles repeat through history, and techies giving newer yet similar security solutions, yet consumers facing the same pitfalls, I ask myself: have we learned anything as consumers of technology??