Split Tunnel Insecurities
I really dislike corporate VPNs that don’t allow split tunneling—disconnecting from the VPN to print on a local printer, or access a local network attached drive, puts a real crimp in productivity. In the case of services reachable over both IPv6 and IPv4, particularly if the IPv6 path is preferred, split tunneling can be quite dangerous, as explained in RFC7359. Let’s use the network below to illustrate.
In this network, host A is communicating with server B through a VPN, terminated by the VPN concentrator marked as “VPN.” Assume the host is reachable on both 192.0.2.1 and 2001:fb8:0:1::1. The host, the upstream router, the network in the cloud, and the server are all IPv6 reachable. When the host first connects, it will attempt both the IPv6 and IPv4 connections, and choose to use the IPv6 connection (this is what most current operating systems will do).
The problem is: the VPN connection doesn’t support IPv6 at all—it only supports IPv4. Because IPv6 is preferred, the traffic between the host and the server will take the local IPv6 connection, which is not encrypted—the blue dash/dot line—rather than the encrypted IPv4 tunnel—the red dashed line. The user, host, and Continue reading
Worth Reading: The great DevOps train wreck
The post Worth Reading: The great DevOps train wreck appeared first on 'net work.
Container Networking Breaking Out
Docker containers are clearly transforming nearly every aspect of IT these days – and networking is no exception.
Delivering a Seamless Guest Experience
Author: Diana Shtil, Product Marketing Manager The Hospitality Industry Technology Exposition and Conference (HITEC) 2016 took place in New Orleans last week, bringing together over 300 companies who all specialize in products, services, and solutions for the hospitality industry. From...What is Google Up To?
The astonishing rise and rise of the fortunes of Google has been one of the major features of both social and business life of the early 21st century. In the same way that Microsoft transformed the computer into a mainstream consumer product, Google has had a similar transformative effect upon its environment.The complete guide to Go net/http timeouts
When writing an HTTP server or client in Go, timeouts are amongst the easiest and most subtle things to get wrong: there’s many to choose from, and a mistake can have no consequences for a long time, until the network glitches and the process hangs.
HTTP is a complex multi-stage protocol, so there's no one-size fits all solution to timeouts. Think about a streaming endpoint versus a JSON API versus a Comet endpoint. Indeed, the defaults are often not what you want.
In this post I’ll take apart the various stages you might need to apply a timeout to, and look at the different ways to do it, on both the Server and the Client side.
SetDeadline
First, you need to know about the network primitive that Go exposes to implement timeouts: Deadlines.
Exposed by net.Conn with the Set[Read|Write]Deadline(time.Time) methods, Deadlines are an absolute time which when reached makes all I/O operations fail with a timeout error.
Deadlines are not timeouts. Once set they stay in force forever (or until the next call to SetDeadline), no matter if and how the connection is used in the meantime. So to build a timeout with SetDeadline you'll have to Continue reading