Skip to main content

Disabling HTTP WebSub for HTTPS Feeds

FeedMail supports WebSub for real-time feed updates. WebSub is a great technology that allows faster and more efficient content distribution. However WebSub hubs have the ability to inject arbitrary content into feeds. This is normally not an issue because feed owners will use hubs that they trust. The decentralized nature of WebSub even allows feed owners to run their own hub and trust no one.

However if a WebSub hub is hosted over unencrypted http:// anyone who can see traffic between the subscriber (in this case FeedMail) and the hub can inject arbitrary content into the feed. We consider this too risky for too little benefit and will be removing support for this configuration.

When a user sees an https:// feed they expect that it is private and secure. In order to maintain this expectation FeedMail already takes a number of precautions.

  • https:// to http:// redirects for feeds are not followed.
  • Feed URLs are never updated to http:// URLs. (Generally, FeedMail follows feed URL changes.)

This change should ensure that users can trust the content of any https:// feeds.

What's Changing

Starting May 24th FeedMail will no longer use WebSub for https:// feeds if the WebSub hub is not https://. Affected feeds will continue to be polled like other non-WebSub feeds. If a feed specifies both http:// and https:// hubs the https:// ones will be used.

Update May 24th: This change is now active. No new insecure subscriptions will be made on insecure hubs. 

Updates from existing http:// hub subscriptions will continue to be accepted until the end of their lease (up to 7 days) at which point they will be ignored.

Example

If https://example/feed.atom contains a link to the hub http://example/hub that hub will be ignored. In order to use WebSub for https:// feeds the hub must be https:// as well.

Exception

pubsubhubbub.appspot.com is the most popular hub and it supports HTTPS. However many feeds reference it using http://. FeedMail will use the https:// endpoint for these feeds as if that is what they specified. This is not expected to cause any problems and will simply improve security.

This exception may be removed at any time, we highly recommend that feed owners update their feeds to reference the https:// endpoint. It should require no other changes on your part.

Effect

This is expected to have no significant impact on users. Despite FeedMail subscribing to hundreds of feeds via WebSub, only 8% of those feeds currently have this issue.

Of those, 75% will be covered by the above exception.

The remaining 25% feeds are all using http://medium.superfeedr.com/ as a hub. This hub is intended for use by Medium which has a broken WebSub implementation that never sends updates. This means that ignoring this hub will actually improve update speed as FeedMail will poll more often.

So in conclusion, 8% feeds will become more secure and 2% of those will also update faster. No current feeds will become worse in any way.

For Feed Owners

If you are a feed owner please inspect your feeds for links that start with http://. These links hurt your reader's privacy and risk the integrity of your content. We recommend using https:// for all links even if they are covered by the above exception.

If you are still unsure of how this change will affect your feed feel free to reach out to FeedMail support.

Labels:

Comments

Post a Comment

Popular posts from this blog

Delay on YouTube Feeds

Most YouTube feeds have not sent new notifications since 2023-10-02 14:20 UTC. We will be triggering a manual YouTube feeds over the next hour and all missing notifications will be sent. If you have any missing notifications after 2023-10-05 14:00 UTC please reach out to support. Update 14:00 : All updates have been sent. If you believe that you are still missing updates feel free to reach out. The rest of this post is a technical analysis of the issue. Background This was caused due to recent emergency response to YouTube WebSub notifications. The emergency response was necessary is due to the following factors. YouTube WebSub posts are not spec compliant and do not contain the required information to send notifications. Therefore FeedMail uses these notifications as a "ping" to re-fetch the feed. YouTube often sends notifications before the entries appear in the feed. The exact reason is not known but sometimes entries do not appear for up to an hour after the WebSub push. ...
Post a Comment
Read more

Invalid DKIM Signature for Some Mail

As of 2023-07-26 FeedMail messages sent via AWS SES have an invalid feedmail.org DKIM signature. This may result in messages ending up in your spam folder. This is an ongoing issue and updates will be posted here as they are available. 2023-09-25 We have issue an update that should avoid SES re-formatting signed fields. This is a workaround but should result in valid signatures. Who is affected? This is unlikely to affect most of our users for the following reasons: 97% of our mail is sent by us directly, not via AWS. This mail still has a SPF-verified sending IP. However this may still affect users because spam filters may consider these messages less "good" than they would have been with a valid DKIM signature. The most notable Inbox Providers affected by this are Apple and Microsoft. FeedMail uses AWS SES for these providers as they reject all messages from our network provider. However other smaller providers may also have a portion of their messages sent via AWS SES. ...
Post a Comment
Read more

Support for SMTP MTA Strict Transport Security

FeedMail now supports SMTP MTA Strict Transport Security (MTA-STS) . This standard provides receiving domains a way to attempt to indicate that incoming mail should only be delivered over a secure connection. When FeedMail receives this signal it will refuse to deliver over insecure connections (retrying mail as required). FeedMail does not currently support SMTP TLS Reporting (TLSRPT) . We will be reaching out to any existing customers who's mail may be rejected due to this change.
Post a Comment
Read more