Currently a client can create a channel and join it (e.g. call /v1/ws/SomeChannelId vs. requesting a new channel via /v1/ws/). We should only allow channel joins to occur if the channelID is known and active.

This is an open-ended discussion, I think what we have right now is fine for first iteration, but I don't want to lose track of this thought...

Right now we use v4 uuid as channel identifiers. This provides strong uniqueness guarantees, but makes the channel id very long. That's fine for our first version where they're transferred between devices via QR code.

In the future, we expect to have some flows where the user has to type in the connection information by hand, including the channel id and some secret PAKE key. A uuid would be far too long to use in such flows.

What would it look like to make the channel ids here as short as possible, say only three or four base32 alphabet characters long?

Right now docker run gives me:

docker run --rm --name pairsona mozilla/pairsona:latest
Sep 18 14:22:51.398 ERRO Cannot find geoip database: mmdb/latest/GeoLite2-City.mmdb

Builds are failing here due to security advisories and required upgrades.

The pairsona page should connect directly to the push connection server. This should aid in exchanging "raw" data between two instances.

There is a WIP for adding metrics.

Currently, get_remote does not filter private network addresses. These include

10.0.0.0/8
172.16.0.0/12
192.168.0.0/16
127.0.0.1/32

Currently it appears that there's no websocket pings being generated by parisona or the client. this is causing some connections to idle out before we want.

Recently updated commit (2fd37e6) cause docker image error:

/app/bin/channelserver: /lib/x86_64-linux-gnu/libc.so.6: version GLIBC_2.25' not found (required by /app/bin/channelserver)`

Debian:stretch has glibc 2.24 from ldd --version

So debian in Dockerfile should at least be upgraded to buster.

Right now, unit tests for channelserver are a bit limited. test_chan opens up a connection to a target server and runs a quick suite of integration tests to proof that things are working correctly.

These need to be expanded and improved.

MaxMind publishes test location databases. We should incorporate that into our local CI testing.

We're opening this issue because your project has used Travis CI within the last 6 months. If you have already migrated off it, you can close and ignore this issue.

Travis CI is ending free builds on public repositories. travis-ci.com stopped providingthem in early November, and travis-ci.org will stop after December 31, 2020. To avoid disruptions to your workflows, you must migrate to another CI service.

For production use cases, we recommend switching to CircleCI. This service is already widely used within Mozilla. There is a guide to migrating from Travis CI to CircleCI available here.

For non production use cases, we recommend either CircleCI or Github Actions. There is a guide to migrating from Travis CI to Github Actions available here. Github Actions usage within Mozilla is new, and you will have to work with our github administrators to enable specific actions following this process.

If you have any questions, reach out in #github-admin:mozilla.org on matrix.

Removing travis-ci from build requirement for this project.

Please use circle-ci instead.

(Related to mozilla-services/services-engineering#60)

Currently the integration testing is being done via an external python application. This needs to be integrated to travis.

Currently the production channelserver seems to timeout channels after 30 seconds.

@jbuck to increase that and match it with the dev values, I think those values are in minutes.

I think this should live at https://channelserver.services.mozilla.com - any objections?

There's no API document for using or communicating with the ChannelServer since it's all been done mostly informally.

The Proof of Concept system needs to be either ported over or properly rewritten so that it uses libraries that are not broken or otherwise unable to run on all current firefox versions, and is more professional.

Right now, the actor handling the socket is killed when it receives an Actix message containing just a ^D. This is probably not the best way to do this. Need to investigate a proper way to terminate the actor on a requested socket disconnect.

We should rate-limit the number of pairing attempts that can be made from any given IP address within a certain amount of time.

I don't have strong opinions on how to implement this. We could integrate with the existing fxa-customs-server, which would have the advantage of blocking IP addresses that have been behaving badly in other ways (such as too many signin attempts). But that introduces more coupling between this service and the rest of the FxA stack.

This project does not appear to be using cargo-audit (https://github.com/RustSec/cargo-audit) - that’s strongly recommended in order to be warned about dependencies with security vulnerabilities.

1. Currently channel identifiers are unique UUID4 values, which are too long for many reasons. We need to determine the proper size of the entropy pool and what characters we can use to derive a valid channel ID designate.

2. For scaling, we may want to divvy things up based on endpoint pathing, (e.g. use the first character of the channel path to determine which pool/machine receives the connection). This would ensure that a given connection request returns to the same machine holding state for both sides.

It may be useful to use the channelserver by multiple connections from the same IP.

The server would need to not destroy the channel on first disconnect, as well consider what sort of thread may come from an attacker gaining access to the channel.

In the RRA it's noted that we should expect users to take pictures of these QR codes with their cameras. We can expect QR code images to end up in unexpected places, and looked at by unexpected people. One guard we can put in place is to expire a channel if a Supp does not connect or complete the flow within a certain time. Perhaps we say the channel can exist for 15 minutes w/o the Supp connecting, at which point a new channel must be created. Once the Supp connects, give another 15 minutes to complete the flow.

Thoughts?

Right now it displays:

{
    "build": "TBD",
    "commit": "TBD",
    "source": "https://github.com/mozilla-services/channelserver",
    "version": "TBD"
}

From FoxSec

Risk Management

• The service must have performed a Rapid Risk Assessment and have a Risk Record bug
• The service must be registered via a New Service issue

Infrastructure

• Access and application logs must be archived for a minimum of 90 days
• Use Modern or Intermediate TLS
• Set HSTS to 31536000 (1 year) N/A hosting under services.mozilla.com
  • strict-transport-security: max-age=31536000
  • If the service is not hosted under services.mozilla.com, it must be manually added to Firefox's preloaded pins. This only applies to production services, not short-lived experiments.
• If service has an admin panels, it must: N/A No admin panel
  • only be available behind Mozilla VPN (which provides MFA)
  • require Auth0 authentication

Development

• Ensure your code repository is configured and located appropriately:
  • Application built internally should be hosted in trusted GitHub organizations (mozilla, mozilla-services, mozilla-bteam, mozilla-conduit, mozilla-mobile, taskcluster). Sometimes we build and deploy applications we don't fully control. In those cases, the Dockerfile that builds the application container should be hosted in its own repository in a trusted organization.
  • Secure your repository by implementing Mozilla's GitHub security standard.
• Sign all release tags, and ideally commits as well
  • Developers should configure git to sign all tags and upload their PGP fingerprint to https://login.mozilla.com
  • The signature verification will eventually become a requirement to shipping a release to staging & prod: the tag being deployed in the pipeline must have a matching tag in git signed by a project owner. This control is designed to reduce the risk of a 3rd party GitHub integration from compromising our source code.
• enable security scanning of 3rd-party libraries and dependencies
  • Use nsp check for node.js (see usage in FxA and screenshots)
  • For Python, enable pyup security updates:
    • Add a pyup config to your repo (example config: https://github.com/mozilla-services/antenna/blob/master/.pyup.yml)
    • Enable branch protection for master and other development branches. Make sure the approved-mozilla-pyup-configuration team CANNOT push to those branches.
    • From the "add a team" dropdown for your repo /settings page
      • Add the "Approved Mozilla PyUp Configuration" team for your github org (e.g. for mozilla and mozilla-services)
      • Grant it write permission so it can make pull requests
    • notify [email protected] to enable the integration in pyup
• Keep 3rd-party libraries up to date (in addition to the security updates)
  • For NodeJS applications, use renovate or [GreenKeeper](https://greenkeeper.io/ Greenkeeper)
  • For Python, use pip list --outdated or requires.io or pyup outdated checks
  • For Rust, use cargo update and cargo upgrade when changing versions
• Integrate static code analysis in CI, and avoid merging code with issues
  • Javascript applications should use ESLint with the Mozilla ruleset
  • Python applications should use Bandit
  • Go applications should use the Go Meta Linter
  • Use whitelisting mechanisms in these tools to deal with false positives

Dual Sign Off

• Services that push data to Firefox clients must require a dual sign off on every change, implemented in their admin panels
  • This mechanism must be reviewed and approved by the Firefox Operations Security team before being enabled in production

Logging

• Publish detailed logs in mozlog format (APP-MOZLOG)
  • Business logic must be logged with app specific codes (see FxA)
  • Access control failures must be logged at WARN level

Security Headers

• Must have a CSP with
  • a report-uri pointing to the service's own /__cspreport__ endpoint
  • web API responses should return default-src 'none'; frame-ancestors 'none'; base-uri 'none'; report-uri /__cspreport__ to disallowing all content rendering, framing, and report violations
  • if default-src is not none, frame-src, and object-src should be none or only allow specific origins
  • no use of unsafe-inline or unsafe-eval in script-src, style-src, and img-src
• Web APIs must set a non-HTML content-type on all responses, including 300s, 400s and 500s
• Set the Secure and HTTPOnly flags on Cookies, and use sensible Expiration No cookies
• Make sure your application gets an A+ on the Mozilla Observatory
• Verify your application doesn't have any failures on the Security Baseline.
  • Contact secops@ or ping 'psiinon' on github to document exceptions to the baseline, mark csrf exempt forms, etc.
• Web APIs should export an OpenAPI (Swagger) to facilitate automated vulnerability tests

Security Features

• Authentication of end-users should be via FxA. Authentication of Mozillians should be via Auth0/SSO. Any exceptions must be approved by the security team. N/A No Users.
• Session Management should be via existing and well regarded frameworks. In all cases you should contact the security team for a design and implementation review N/A No Sessions.
  • Store session keys server side (typically in a db) so that they can be revoked immediately.
  • Session keys must be changed on login to prevent session fixation attacks.
  • Session cookies must have HttpOnly and Secure flags set and the SameSite attribute set to 'strict' or 'lax' (which allows external regular links to login).
  • For more information about potential pitfalls see the OWASP Session Management Cheat Sheet
• Form that change state should use anti CSRF tokens. Anti CSRF tokens can be dropped for internal sites using SameSite session cookies where we are sure all users will be on Firefox 60+. Forms that do not change state (e.g. search forms) should use the 'data-no-csrf' form attribute.
• Access Control should be via existing and well regarded frameworks. If you really do need to roll your own then contact the security team for a design and implementation review.
• If you are building a core Firefox service, consider adding it to the list of restricted domains in the preference extensions.webextensions.restrictedDomains. This will prevent a malicious extension from being able to steal sensitive information from it, see bug 1415644.

Databases

• All SQL queries must be parameterized, not concatenated N/A No DB
• Applications must use accounts with limited GRANTS when connecting to databases
  • In particular, applications must not use admin or owner accounts, to decrease the impact of a sql injection vulnerability.

Common issues

• User data must be escaped for the right context prior to reflecting it N/A No user data or Info reflection
  • When inserting user generated html into an html context:
    • Python applications should use Bleach
    • Javascript applications should use DOMPurify
• Apply sensible limits to user inputs, see input validation
  • POST body size should be small (<500kB) unless explicitly needed
• When managing permissions, make sure access controls are enforced server-side
• If caching is used then make sure that any data cached does not incorrectly allow allow access to data protected by access control
• If handling cryptographic keys, must have a mechanism to handle quarterly key rotations
  • Keys used to sign sessions don't need a rotation mechanism if destroying all sessions is acceptable in case of emergency.
• Do not proxy requests from users without strong limitations and filtering (see Pocket UserData vulnerability). Don't proxy requests to link local, loopback, or private networks or DNS that resolves to addresses in those ranges (i.e. 169.254.0.0/16, 127.0.0.0/8, 10.0.0.0/8, 100.64.0.0/10, 172.16.0.0/12, 192.168.0.0/16, 198.18.0.0/15).
• Do not use target="_blank" in external links unless you also use rel="noopener noreferrer" (to prevent Reverse Tabnabbing)

it appears that actix takes a very simple view of how the remote address is resolved, which may lead to potential header spoofing. We may want to handle extracting the remote IP address from the request headers ourselves.

Metrics does it's own ref counting, so it doesn't need to be isolated in a refcell. Likewise, settings doesn't need to be cloned to be stored in the ChannelServer class.

The initial test hit a fluke which allowed a first participant to send messages to the second, but not the other way around. Digging in, the problem was that the second participant wasn't being added to the group set properly.

A basic linkserver that can:

1. Serve static assets for the base webpage
2. Handle websocket connections to relay data
3. Handle PUT requests to send data to a connected client

How are we going to deploy updates when their are users already connected to a channel? Will we deploy a new stack and wait for all users to drain off the old stack before decommissioning it? Will we just break the connection of the existing users and write some reconnect logic that connects to the new stack?

(Still need to know what encoding, URL safe or standard)

The demo code had channel_route be a function passed to the .f() method. This should probably be refactored as a From Request extractor.

May also want to look at the internals for r.method().f() to see if the same sort of pattern should be applied as well.

See https://cloud.google.com/load-balancing/docs/backend-service#user-defined-request-headers

Currently the code is doing a few things that could be simplified by using a middleware layer. (e.g. the SecOps headers, pulling the GCP location header, etc.)

We intend for the server component here to be called "channelserver", but the repo is currently publishing docker images to "mozilla/pairsona" because that's the name of the repo. Can we please update $DOCKERHUB_REPO in circleci config to be "channelserver"?

/cc @jrgm

Tracking issue for ChannelServer 0.4.0 deployment requests

https://bugzilla.mozilla.org/show_bug.cgi?id=1501853

Firefox Accounts has a bug over here mozilla/fxa#5426 where strings are showing up in German on desktop. The comments lead to channelserver and JR suggested I file this here. Please read the linked issue for context

@jrconlin and I were trying to get a grafana dashboard together that included the statsd metrics channelserver sends. Testing in stage revealed that no metrics were getting sent. I tested locally using nc -u -l 8529 to listen for statsd metrics but didn't see any. I changed the BufferedUdpMetricSink to a UdpMetricSink and I started to see some test metrics I set, but I don't see any of the regular metrics like conn.max.data or conn.max.msg

As of January 1 2019, Mozilla requires that all GitHub projects include this CODE_OF_CONDUCT.md file in the project root. The file has two parts:

1. Required Text - All text under the headings Community Participation Guidelines and How to Report, are required, and should not be altered.
2. Optional Text - The Project Specific Etiquette heading provides a space to speak more specifically about ways people can work effectively and inclusively together. Some examples of those can be found on the Firefox Debugger project, and Common Voice. (The optional part is commented out in the raw template file, and will not be visible until you modify and uncomment that part.)

If you have any questions about this file, or Code of Conduct policies and procedures, please reach out to [email protected].

(Message COC001)

Ensure the app can operate and communicate with the proposed Ops security infrastructure.

This should include:

• Standardized error logging for infractions
• Process SecOps provided Header correctly (rejecting invalid requests if appropriate)

Currently test_chan is run as an app rather than via pytest. All the functions and tests are run, however under pytest, the app hangs when trying to recv data for some reason.

See PR #78

It has been requested that the two sides should exchange some elements of metadata along with the crypto block being exchanged.

The sender format may be JSON and similar to:

{
 "data":"aB12Cx...", 
 "browser":"nightly",
 "os":"Windows 10",
 "device":"desktop"
}

This would be extended by the channelserver to include some information based on the incoming IP (e.g. ...

{
  ...
  "remote": {
     "IP": "fe80::e3aa:8e62:4ad5:c3c6",
     "location":"London, UK",
     "browser": "nightly",
     "os": "Windows 10",
   }
}

and sent to the receiver.

The socket appears to be left in a half-open state when the close request is sent. Further messages will fail, but it does not appear that a close message is being sent to the remote websocket client.