Measuring QUIC and TLS censorship with OONI Probe

About Me

Kathrin Elmenhorst, final year B.Sc. CS student, from Osnabrueck, Germany.
I am interested in digital rights and tech education.

About My Project

I will be working with the team at the Open Observatory of Network Interference (OONI) to develop network experiments measuring the blocking of websites via TLS and QUIC. I will also work on the further integration of my previous contribution which is an HTTP/3 (HTTP over QUIC) extension for the OONI engine.
GSoC project

My Time Zone

Central European Time (UTC+2)

Getting in Touch

Please message me if you are interested in my project or want to chat about all things Internet and society.

May 24, 2021 - June 4, 2021: Community Bonding

  • Me and my fellow GSoC student at OONI were welcomed by the team in an introductory meeting. We talked about the modes of agile operation at OONI and got introduced to the used organizational tools, such as the Zenhub extension for issue organization. We agreed on the level and ways of our participation in the team and planned for us students to take part in the bi-weekly sprint meetings.
  • I am following and participating in various OONI Slack channels, so I know what is going on in the community.
  • I had a meeting with my mentor where we talked about the specifics of my project and planned the first steps of the coding phase.
  • I wrote and submitted the issue for my first week of coding so I am ready to start off directly.
1 Like

June 7, 2021 - June 11, 2021: Start of the coding period

  • I participated in the bi-weekly sprint planning meeting. I learned how these meetings work and that tasks are not only defined for each team member, but can also be labeled as “team priority” for issues that are prioritized to be completed during this sprint and require team collaboration.
  • I started working on a refactoring project regarding the mapping of network errors to OONI censorship-related error strings. The goal of this refactoring is to dissolve packet dependencies and localize the error wrapping. The refactoring touched many parts of the codebase and allowed me to get familiar again with the OONI engine, and I already learned more about Golang coding.
  • The refactoring will hopefully completed next week. Afterwards I want to start researching more about TLS parroting.

June 14 - June 18

What I did:

Finished the refactoring for error classification.

  • improved handling of QUIC errors, by
    a) importing QUIC error codes from quic-go
    b) importing TLS alert codes from the RFC
    c) generally stop relying on possibly changing error strings
  • improved handling of system errors: introduced system errno constants to detect and identify system errors
    → this solved the problem of detecting localized windows error strings (issue 1526)
  • divided the classifier code (that translates errors into OONI error strings) by layers, so that each of the following protocol layers has it‘s own classifier with layer-specific errors
    ⁃ QUIC
    ⁃ TLS over TCP
    ⁃ resolve
    A general classifier remains to handle errors that can occur on multiple layers.
    → this change helps with the maintainability of the classification code and improves the interface of the errorx package and therefore fulfills the requirements defined in issue 1505.


  • During this week, with my mentor I found out, that the original refactoring design of introducing layer/operation specific error types will not work with the current architecture of OONI Probe. This is, among other reasons, due to the fact that potentially occurring errors can not be sharply separated between operations. Furthermore, the current codebase relies on the classification results in many places, more than expected, so it became evident that having a single error wrapper type, with a field defining the failed operation, is the best solution for the time being.
    → the planned error wrapping refactoring therefore became an error classification refactoring: the localization of layer-specific errors as originally planned was not realized by introducing operation-specific error wrappers, but by subdividing the classification code used by the single error wrapper.
  • This week, I struggled with structuring my work time and planning the immediate To Do‘s. Although the outcome of this week‘s work was met the requirements and original plan, I want to be more intentional and organized when it comes to my own time and task management. I communicated this with my mentor and we agreed to schedule a weekly Monday meeting to layout the week ahead and discuss the extent and time frame of upcoming tasks.

Next week:

  • I will start tackling the TLS parroting issue: After continuing my research on this topic I want to have a clear design idea for implementing TLS parroting in OONI Probe at the end of the next week.
  • I will stay in close communication with my mentor, exchange ideas and get feedback about my implementation ideas.
  • In terms of deliverables, this means: I will do proof of concept tests, and provide a graphic draft of the design.