Monthly Archives: October 2014
Traffic Server Summit (by ‘net)
I spent two days last week at the trafficserver summit.
Or rather, two evenings. The summit was held in Silicon Valley (hosted by linkedin), while I remained at home in Blighty with a conferencing link, making me one of several remote attendees. With an 8 hour time difference, each day started at 5pm and went on into the wee hours. On the first day (Tuesday) this followed a day of regular work. On the Wednesday I took a more sensible approach and the only work I did before the summit was a bit of gardening. Despite that I felt more tired on the Wednesday.
The conferencing link was a decent enough instance of its kind, with regular video alongside screen sharing and text (though IRC does a better job with text). The video was pointed at the speakers as they presented, and the screen sharing was used to share their presentations. That was good enough to follow the presentations pretty well: indeed, sometimes better than being there, as I could read all the intricate slides and screens that would’ve been just a blur if I’d been present in the room.
Unfortunately most of the presentations involved discussion around the room, and that was much harder, sometimes impossible, to follow. Also, speaking was not a good experience: I heard my voice some time after I’d spoken, and it sounded ghastly and indistinct, so I muted my microphone. That was using just the builtin mike in the macbook. I tried later with a proper headset when I had something to contribute, but alas it seems by then I (and I think all remote attendees, after the initial difficulties) was muted by the system. So I had something approximating to read-only access. And of course missed out on the social aspects of the event away from the presentations.
In terms of the mechanics of running an event like this, I think in retrospect we could make some modest improvements. We had good two-way communication over IRC, and that might be better-harnessed. Maybe rather than ad-hoc intervention, someone present (a session chair?) could act as designated proxy for remote attendees, and keep an eye on IRC for anyone looking to contribute to discussion. Having such a person would probably have prompted me into action on a few occasions when I had a comment, question or suggestion. Or perhaps better, IRC could be projected onto a second screen in the room, alongside the presenter’s materials.
The speakers and contents were well worth the limitations and antisocial hours of attending. I found a high proportion of the material interesting, informative, and well-presented. Alan, who probably knows more than anyone about Trafficserver internals, spoke at length on a range of topics. The duo of Brian and Bryan (no, not a comedy act) talked about debugging and led discussion on test frameworks.
Other speakers addressed applications and APIs, and deployments, ops and tools. A session I found unexpectedly interesting was Susan on the subject of how, in integrating sophisticated SSL capabilities in a module, she’s been working with Alan to extend the API to meet her needs. It’s an approach from which I might just benefit, and I also need to take a look at whether Ironbee adequately captures all potentially-useful information available from SSL.
At the end I also made (via IRC) one suggestion for a session for the next summit: API review. There’s a lot that’s implemented in Trafficserver core and utils that could usefully be made available to plugins via the API, even just by installing existing header files to a public includes directory. Obviously that requires some control over what is intended to be public, and a stability deal over exported APIs. I have some thoughts over how to deal with those, but I think that’s a subject for the wiki rather than a blog post. One little plea for now: let’s not get hung up on what’s in C vs C++. Accept that exported headers might be either, and let application developers deal with it. If anyone then feels compelled to write a ‘clean’ wrapper, welcome their contribution!
To phish, or not to phish?
I recently had email telling me my password for $company VPN is due to expire, and directing me to a URL to update it.
Legitimate or phishing? Let’s examine it.
It follows the exact form of similar legitimate emails I’ve had before. Password expires in 14 days. Daily updates decrementing the day count until I change it. So far so good.
However, it’s directing me to an unfamiliar URL: https://$company.okta.com/. Big red flag! But $company outsources a range of admin functions in this manner, so it’s entirely plausible.
It appears to come from a legitimate source. But since all $company email is outsourced to gmail, the information I can glean from the headers is limited. How much trust can I place in gmail’s SPF telling me the sender is valid?
A look on $company’s intranet fails to find anything relevant (though in the absence of a search function I probably wouldn’t find it anyway without a truly gruelling trawl). OK, let’s google for evidence of a legitimate connection between $company and okta.com. I’ve resolved similar problems to my own satisfaction that way before both for $company and other such situations (e.g. here or here), but the hurdle for a $company-VPN password – even one I’m about to change – has to be high.
Googling finds me only inconclusive evidence. There’s a linkedin page for $company’s sysop, only it turns out he’s moved on and the linkedin page is just listing both $company and okta skills in his CV. There’s a PDF at $company’s website with instructions for setting up some okta product (though it’s one of those that insults you with big cuddly pictures of selecting a series of menu options without actually saying anything non-obvious).
Hmmm …
OK, maybe I can get okta.com to prove itself, with the kind of security question your bank asks when you ‘phone it. Let’s use okta’s “Password Reset”. I expect it’ll send a one-off token I can use to set a new password. If legit, that’ll work; if not then the newly-minted password is worthless and I just abandon it. But no such thing: instead of sending me such a token, it tells (emails) me:
Your Okta account is configured to use the same password you currently use for logging in to your organization’s Windows network. Use your Windows account password to sign in to Okta. Please use the password reset function in Windows to reset your password.
Well, b***er that. Windows account password? Windows network? I have no such thing, and neither does $company expect me to. I expect $company may have a few windows boxes, but they’re certainly not the norm. No doubt it just means the LDAP password I’m supposed to be changing, but if I know that then why should I be asking it for password reset? Bah, Humbug!
One more thing to try before a humiliating request for help over something I should be able to deal with myself. Somewhere in my gmail I can dig up previous password reset reminders, with a URL somewhere on $company’s own intranet. Try that URL. Yes, it still works, and I can reset my VPN password there. All that investigation for … what?
Well, there’s a value to it. Namely the acid test: does the daily password reminder stop after I’ve reset the password? If it’s genuine then it shares information with $intranet and knows I’ve reset my password. If it’s a phish then it knows nothing. So now I’m getting some real evidence: if the password reminders stop then it’s genuine.
They do stop. So I conclude it is indeed genuine.
Unless it’s so ultra-sophisticated that it’s been warned off by my having visited the site and used password reset, albeit unsuccessfully. Waiting to try again in a few months? Hmmm ….
Well, if $company hasn’t outsourced it then the intranet-based password reset will continue to work next time. If it doesn’t work next time then there’s one more piece of evidence it’s genuine.
niq's soapbox 