achernya | 3 years ago | on: Mosh: An Interactive Remote Shell for Mobile Clients (2012) [pdf]
achernya's comments
achernya | 3 years ago | on: Mosh: An Interactive Remote Shell for Mobile Clients (2012) [pdf]
The only mosh CVE [1] was in the terminal emulator (a DoS that could only be triggered by a local user), not in the protocol. There have been no vulnerabilities in mosh's UDP protocol.
achernya | 4 years ago | on: Unlocking QUIC’s proxying potential with MASQUE
QUIC datagrams not having a stream ID was a compromise, which is why the H3-DGRAM draft exists to add them. Any other protocol can use cite and use H3-DGRAM even if it itself is not using HTTP/3.
achernya | 4 years ago | on: An update on the threat landscape
https://peering.google.com/#/infrastructure has maps of Google CDN infrastructure.
(work at Google, and on the CDN)
achernya | 4 years ago | on: Proposed futex2 allows Linux to mimic the NT kernel for better Wine performance
futex is a Fast Userspace muTEX. It's the syscall to help implement a mutex when there are two or more threads waiting on the lock to let other processes/threads schedule and do useful work during the wait.
achernya | 4 years ago | on: QUIC and HTTP/3 Support Now in Firefox Nightly and Beta
Following up on this, there's discussion on github [1] about this, and we're currently leaning towards allowing URIs.
[1] https://github.com/DavidSchinazi/draft-cms-masque-connect-ip...
achernya | 5 years ago | on: QUIC and HTTP/3 Support Now in Firefox Nightly and Beta
Right now we're focusing on building a functional core protocol and making sure it's sufficiently extensible. It should be possible to build chaffing as an add-on extension down the line.
achernya | 5 years ago | on: QUIC and HTTP/3 Support Now in Firefox Nightly and Beta
We have built a VPN over QUIC, and the core code is open source already [0].
We're working on standardizing "IP Proxying" over QUIC as part of the MASQUE working group at IETF. So far, we've adopted a requirements document [1] and have started work on an implementation [2].
[0] https://quiche.googlesource.com/quiche/+/refs/heads/master/q...
[1] https://tools.ietf.org/html/draft-ietf-masque-ip-proxy-reqs-...
[2] https://tools.ietf.org/html/draft-cms-masque-connect-ip-00
achernya | 5 years ago | on: Enzyme: Cross-language Automatic differentiation for LLVM IR
It looks like the links to the code have some junk characters at the end. It should be https://github.com/wsmoses/Enzyme.
achernya | 8 years ago | on: By installing NAT, MIT stifles innovation
Author here -- MIT does not currently have IPv6. Although MIT did receive a /24 IPv6 allocation, https://whois.arin.net/rest/net/NET6-2603-4000-1, it's not routable everywhere on campus yet.
Unfortunately, IPv6 deployment is still below 20% (as measured by Google, https://www.google.com/intl/en/ipv6/statistics.html) so a publically-accessible IPv6 address is not yet sufficient.
achernya | 9 years ago | on: Achieving a Perfect SSL Labs Score with Go
The specific detail that you've noticed in the Go implementation has to do with RFC 7540, Section 9.2.2 (https://tools.ietf.org/html/rfc7540#section-9.2.2) which requires TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 for TLS 1.2 only. Deployments of the future TLS 1.3 are free to not support this cipher, if I am reading the RFC correctly.
That is to say, you're correct that server configured for a 100% on SSLLabs will not support HTTP/2, but I agree with davidben that SSLLabs is incorrect here for incetivising AES-256, particularly in CBC mode, for the 100% score.
achernya | 10 years ago | on: Understanding GNU Screen's captions
I ran a nearly identical screen theme for a long time, before switching to byobu. Nice to see this broken down, screen's format strings are quite dense.
achernya | 10 years ago | on: What ISPs can see
That is not sufficient -- TLS Server Name Indication (SNI) is still cleartext in the handshake.
achernya | 10 years ago | on: A struggle within MIT’s IT department over its future
> In addition, the tech support was wonderful. A few years after I graduated I remembered a blog I had kept from my athena account, and emailed in to ask if they happened to still have it. They kind of did; they sent me a SQL dump of its contents, which was enough for me.
While it's true that helpdesk at IS&T was all sorts of wonderful prior to the transformation, that particular example wasn't handled by them, but rather by the student volunteers running Scripts (scripts.mit.edu), part of SIPB (sipb.mit.edu). SIPB does get its funding from IS&T, and worked pretty closely with many people there on initiatives ranging from the Scripts platform to the whole Athena operating system.
I don't know if the "fast and free infrastructure" and "friendly tech support" will continue, as it requires the new IS&T to continue supporting the student volunteers.
achernya | 10 years ago | on: Xv6, a simple Unix-like teaching operating system
Which qemu are you cloning? When we taught 6.828 over IAP term we ported the patches to qemu 1.7.0 and put them up at https://github.com/geofft/qemu. I see the repo has a 2.3.0 and 2.4.0 branch now too. I last built 1.7.0 on Debian 6 (squeeze); newer Debian and Ubuntu should work fine. (Make sure you have libsdl1.2-dev installed)
achernya | 10 years ago | on: Ispy: A python script for monitoring the output of other terminals and processes
Is there a comparison of reTTY with reptyr (https://github.com/nelhage/reptyr)? reptyr claims to work with less while reTTY does not.
achernya | 11 years ago | on: Why Google won't fix a security bug in almost a billion Android phones
It's not that much of a myth. When Google first announced that the Galaxy Nexus was not getting KitKat, I was pretty disappointed, as I had one too. I looked into why there was no official support, and when I found out it had to do with the firmware, my gut reaction was "WTF, that makes no sense." Digging some more, I found out that it actually has to do with kernel driver-firmware compatibility. Google wanted to ship an update, but they needed changes that TI was no longer willing/capable of making. In order to release KitKat on the Galaxy Nexus would either require Google to reverse engineer the hardware and make their own radio firmware (not likely) or holding back the kernel to the same one on 4.3 (subpar experience if it even works).
Neither the Glass nor Moto 360 suffer from this problem since neither has a cellular radio.
achernya | 11 years ago | on: Why Google won't fix a security bug in almost a billion Android phones
I'm not sure it's reasonable to expect Google to update a device to the latest version when the hardware manufacturer has exited the market -- http://www.cnet.com/news/google-to-samsung-galaxy-nexus-owne.... While Google does control Android, that's not the only software that is present on the phone. Short of the Nexus series starting to have open source baseband and radio firmware, we'll be at the mercy of hardware manufacturers.
achernya | 11 years ago | on: OpenBSD's kernel gets W^X treatment
You're correct, the protection is implemented in hardware, but the pages have to be marked appropriately. This message describes a patchset that correctly marks the kernel pages as writable xor executable.
achernya | 11 years ago | on: Lab 1: Booting a PC
This was one of my favorite classes, so much that a few of us were crazy enough to offer a January term version of it last year. The material is the same, but the website formatting is for the labs a bit different, and may be more readable to some: https://sipb.mit.edu/iap/6.828/. It's doable to finish all of the labs in an intensive month, and a great experience. I do recommend going through the exercises.
page 1
[1] https://github.com/google/oss-fuzz/tree/master/projects/mosh