Tuesday, May 8, 2012

Are moose heavy? There's mouse.

I happened across Mouse in the dependency chart of an Amazon Route53 module, so I looked it up.
  • Mouse is meant to be lighter than Moose, and compile faster (for CLI and primordial CGI).
  • Mouse wants to let you do s/Mouse/Moose/g and have nothing break, if it turns out Mouse isn't heavy enough.
  • Mouse also exports warnings and strict for you when you use it.
  • Mouse basically doesn't want to have MouseX.
  • Any::Moose gives you Moose if that is already loaded, or Mouse otherwise.
So there you have it: Mouse is a lightweight Moose.  Without antlers.

Updated 2013 Feb 11: Apparently there's also Moo and it's preferred, at least for today.  Because one isn't enough in Perl.

Sunday, May 6, 2012

Python: Slicing in reverse, in the middle of a sequence

When slicing forwards, it's relatively simple to understand: s[7:9] returns a 2-item sequence of elements 7 and 8.  This works pretty much like any other half-open interval, in which one side (the 7) is included and the other (the 9) excluded.  The resulting length is simply the difference between the end and start indexes, 9-7=2.

What about backward? If you reverse the numbers and add a stride value, s[9:7:-1] gives you elements 9 and 8.  Since the interval is still half-open, now 9 is on the closed end and included, and 7 is open and excluded.  So s[8:6:-1] is the reverse of s[7:9].  You're getting two elements, starting at 8 and ending before 6, going backwards.

What happens if you want to get the reverse of s[0:5]?  The above math would suggest s[4:-1:-1] but negative indexes are way at the other end of the sequence, so this produces an empty result.  The correct answer is actually omitting the end index, as in s[4::-1].  That invokes the regular "all items remaining in sequence" meaning, that is also used in s[9:].

Wednesday, May 2, 2012

PPTP is legacy and insecure

Unlike IPSec and L2TP+IPSec, a PPTP VPN tunnel is carried over TCP, which means all packets traveling inside the tunnel are delivered reliably—including any tunneled TCP traffic.  Therefore, the inner TCP layer never sees packet loss, wreaking havoc with its congestion control mechanisms.

Although the RFC refers to the tunnel as "separate", that's only conceptual.  The traffic is carried inside of the single TCP connection.  For example, SSH application data delivered over PPTP is wrapped in its usual TCP/IP, then PPP+GRE (the tunnel/"user data" from PPTP's perspective), then forwarded over the TCP/IP control connection to the PPTP server.

L2TP produces a similar wrapping structure, but the outermost connection is UDP instead.  Its IP frames are wrapped in PPP+GRE and then delivered to the server over UDP/IP.

Consider L2TP+IPSec first.  (At least, my experience with vanilla IPSec has been less than recommendable.)

Update: In the news this year (2012), PPTP's key exchange is broken, and that's actually been known about for years.  There's even a cloud service to crack it for you if you're lazy.  Current advice is actually:
Never use PPTP.

Reference: Moxie Marlinspike's post detailing the 256 complexity of the attack: the md4(password) is used as DES keys which encrypt the same known plaintext, meaning that each DES encryption can potentially reveal any of the segments of the hashed password string. The plaintext password is not necessary for the protocol. As a bonus, the final DES key is padded with five zero octets since the hash isn't long enough for three DES keys.