Restricting api.twitter.com to SSL/TLS traffic

@lfcipriani Luis Cipriani

This is an important notice for developers still using HTTP plaintext connections. On January 14th, 2014, connections to api.twitter.com will be restricted to TLS/SSL connections only. If your application still uses HTTP plaintext connections you will need to update it to use HTTPS connections, otherwise your app will stop functioning. You don't need to wait until deadline to implement this change, given that api.twitter.com already supports the recommended environment.

This SSL requirement will be enforced on all api.twitter.com URLs, including all steps of OAuth and all REST API resources.

Connecting to the API using the SSL protocol builds a safe communication channel between our servers and your application, meaning that no sensitive data can be accessed or tampered by unauthorized agents in the middle of this communication path.

Any well-established HTTP client library already supports the ability to connect to a SSL-enabled server and usually the required change is just a matter of updating a few lines of code or configuration files. For specific details about using SSL to connect at api.twitter.com, please review Connecting to Twitter API using SSL.

A "blackout test" will be performed on Jan 7th, 2014, when HTTP plaintext connections will be unavailable for a time period to be defined and announced in this discussion page and via the @twitterapi account.

If you have any questions or concerns with securely connecting to api.twitter.com over SSL, please post them here.

30 weeks 1 day ago

Replies

@tweetAmattress tweetAmattress

As i recognize the importance of secure connections I know a number of embedded devices that will not be happy with the switch to SSL those devices are build around small micro controllers with little resources like memory and processing power. Those devices are mostly used for sending tweets only.
Maybe its possible to think about a simple non SSL interface for the growing little IoT devices

27 weeks 1 day ago

@lfcipriani Luis Cipriani

The "blackout" test initiated Jan 7th, 19:12 UTC. I will let you know when it ended.

27 weeks 2 hours ago

@lfcipriani Luis Cipriani

The test finished Jan 7th, 21:08 UTC

26 weeks 6 days ago

@Rovskiii Rizky Arya

it's really weird,when i was
tweet i logout and i use
twitter client i got message
code 403 and said version 1.1 i
don't understand. Anybody
know this?

27 weeks 1 hour ago

@artesea Ryan Cullen

Have you broken the rest of the twitter api with this test? My app uses the standard REST api to https://api.twitter.com/ and responses are returning 403 since around the time this blackout started.
The status link above shows problems.

27 weeks 1 hour ago

@artesea Ryan Cullen

So it turns out the code was using http
Thanks for having the blackout during hours sensible for those in the UK.

27 weeks 1 hour ago

@richardhyland Richard Hyland

Yep I'm seeing 403s a lot for signing in at the moment, yes all over https!

27 weeks 1 hour ago

@lfcipriani Luis Cipriani

Please, would be important to check if any library you are using is still doing HTTP plaintext connections. There was some cases like this for other users.

26 weeks 6 days ago

@richardhyland Richard Hyland

I thought I was all SSL'd over until I found a single line in my twitter4j implementation that had an oauth call over plain HTTP. All fixed now :)

26 weeks 6 days ago

@PointBurst1 Point Burst

Could you please specify if it is enough to upgrade the twitter4j library or you just fixed your local version? Thanks in advance

26 weeks 13 hours ago

@ygary Gary Yang

two ways: upgrade to twitter4j 3.0.5, or, add following line to your twitter4j.properties:
http.useSSL=true

25 weeks 5 days ago

@corrego Carlos Orrego

how did your fix it?

i am trying to use configuration builder but it is not working

25 weeks 6 days ago

@Bladeblaster39 jonathan a. parker

25 weeks 6 days ago

@sidhartha11 sidhartha11

In Eclispe, just ste the following VM argument:
-Dtwitter4j.http.useSSL=true

strange that twitter4j team didnt just tell people this instead of making people did thru the code to figure it out. Kindof silly

25 weeks 2 days ago

@AmitNain89 Amit Nain

It will work after setting useSSL true.

ConfigurationBuilder cb = new ConfigurationBuilder();
cb.setUseSSL(true);

Then call the twitter api with https request not http.

Tested on 19 Feb 2014

20 weeks 6 days ago

@priy2609 Priyanka

This worked for me. Thanks.

12 weeks 4 days ago

@karthik54415373 karthikeyan

i am getting following error please help out there i dont what is happening here i am very very new to iOS

014-04-23 14:51:50.190 twitterByAuthenticate[1279:a0b] errorError Domain=STTwitterTwitterErrorDomain Code=220 "Your credentials do not allow access to this resource" UserInfo=0xb561560 {NSUnderlyingError=0xb565440 "HTTP Status 403: Forbidden", NSLocalizedDescription=Your credentials do not allow access to this resource}

11 weeks 6 days ago

@FernandoRubilar FernandoRubilar.

Estimados Señores de red social Twitter.
Siempre he tenido muy buena acogida de parte de ustedes,por eso,muchas gracias.
Mucho se habla de seguridad y protocolo -'https'- en mi sección cuenta; desapareció dicho casillero y,por lo tanto, no tengo casillero protección con https.
Sería su eterno agradecido de su respuesta

27 weeks 1 hour ago

@DustyReagan Dusty Reagan

Very sensible blackout time! Discovered this issue in my apps as well. I thought they were already using SSL! Turns out not completely.

27 weeks 28 min ago

@richardhyland Richard Hyland

Same here, I thought they were all SSL but found my Twitter4J still had a non ssl oauth url in it

26 weeks 6 days ago

@wondDe wonDe

can you share your solution,please? having same issue here.

16 weeks 19 hours ago

@zemaj James Peter

Hi folks,

Is it possible for you to post important notices like these to the blog?

We were a bit blindsided by this as we didn't get any notification that it was going to occur. Previously all similar blackout test have been posted to the announcements blog which sends us email notifications.

If not, is there some other place we can sign up for email notifications of these events? This post just looks like a user's post in the API forum, so it's not clear its an important announcement.

Thank you,
James

26 weeks 6 days ago

@oldergod Benoit Quenaudon

+1 for this one. We also found this news somewhat randomly so would be great to add such impacting news on the blog.
Thank you.

26 weeks 5 days ago

@lfcipriani Luis Cipriani

Yes, we can publish this on the blog. Sorry that you miss this one because it was posted as a discussion topic.

We agree with your requests, there should be a guaranteed way of knowing these changes and we are working on that.

For now, the available ways are:
- Our calendar (https://dev.twitter.com/calendar)
- @twitterapi account
- Our blog (https://dev.twitter.com/blog)
- Sticky posts at Discussions page

26 weeks 5 days ago

@dennydaugherty Denny Daugherty

Announcements such as this should be made much further in advance. I don't see anything before the discussion post less than five weeks before the change took effect. This is not sufficient time to allow developers to update their apps, especially when you take into account busy development schedules and submission time for native mobile applications.

The ability to subscribe to these updates via email would be especially helpful as well. I follow @twitterapi and have added the blog to my news reader, however I am more likely to actually capture an important message if received in an email.

25 weeks 1 day ago

@pgarvie Paul Garvie

@lfcipriani

Couple questions:

Are any further blackouts planned?
What time on Jan. 14th do you guys plan on flipping the switch? The idea being if we know approximately when this is to occur, we can be monitoring our logs to make sure everything continues working.

Thanks!!

PaulG

PS: Here it says this will occur Jan 14th, but in this @twitterapi post it says this will occur on Jan 13th:
https://twitter.com/twitterapi/status/420302564605702144

Could you check that out for us?

26 weeks 5 days ago

@lfcipriani Luis Cipriani

1) No, on January 14th the change will be completely done.
2) I will have this info soon and will post an update here.

ps.: The tweet you mention is about another change that will happen at Streaming API and is related to HTTP 1.0 deactivation. The change announced in this post will be only in api.twitter.com and is related to SSL traffic restriction.

26 weeks 5 days ago

@lfcipriani Luis Cipriani

The deploy will start at 11am PST, Jan 14th

26 weeks 4 days ago

@pgarvie Paul Garvie

Got it. Thanks Luis.

Appreciate it.

PaulG

26 weeks 5 days ago

@fanaticly Fanaticly

Will this also break calls to the TWRequest API in iOS apps? That is, do we need to update the NSURLs we use from http:// to https:// ?

26 weeks 4 days ago

@lfcipriani Luis Cipriani

If these URLs are connecting to api.twitter.com, yes, you need to update it.

26 weeks 1 day ago

@AZOMITE AZOMITE

We fixed ours by just adding an 's' to the http in our twitter.php file. Whoo-hoo. Easy.

25 weeks 1 day ago

@EPEelche ElcheParqEmpresarial

Good morning. I'm developing a web to capture and send tweets and I received the news that as of January 14 using a SSL cerfiticate to use the Twitter API is required.
I have seen that you can get with Verisign and Digicert. My question is Can I use another certificate from another company? What requirements should meet?

26 weeks 1 day ago

@lfcipriani Luis Cipriani

Usually HTTP client libraries available for the language you are using already handle SSL requests. For api.twitter.com you must use only Verisign certificates, given that other certificates won't be validated by your clients.

Please, read the documentation about Connecting to Twitter API with SSL: https://dev.twitter.com/docs/security/using-ssl

26 weeks 1 day ago

@EPEelche ElcheParqEmpresarial

Okay, another question: the only valid certificate for api.twitter.com is Verisign Class 3 Secure Server CA - G3? Are there other valid alternatives?

26 weeks 13 hours ago

@lfcipriani Luis Cipriani

Yes, and there's no other valid alternatives.

26 weeks 10 hours ago

@EPEelche ElcheParqEmpresarial

Thanks

26 weeks 2 hours ago

@HakimGhoula Hakim Jonas Ghoula

I'm using Twython to read from user_timeline and last night my script was working fine now it doesn't. I don't have any http or https in my code so I guess that is handled by twython. Only thing is I was under the impression that it uses https per default. Why am I getting 401s now and how do I go about fixing it?

26 weeks 8 hours ago

@lfcipriani Luis Cipriani

The deploy of this change will start at 11am PST, so at the time of writing it didn't start yet. Your problem can not be related to SSL restriction. But would be interesting to check Twython source code to check if everything will be fine after the restriction is applied.

26 weeks 5 hours ago

@HakimGhoula Hakim Jonas Ghoula

Seems very strange that a script that works fine all of a sudden stops working while running and thus have had no changes to code or dependencies from working state to not working state.

Has anything been changed to oauth version 2?

EDIT: I have now made a new app and it seems to work, now I'm anxious to see if it will also get the same problems.

26 weeks 3 hours ago

@Al_Sweetman Al Sweetman

I've an interesting one here - Hosebird has stopped functioning, today.

Even the "sample code" in the repository returns an IOException (the same as what I'm seeing) - "2014-01-14 17:05:20,506 [hosebird-client-io-thread-0] WARN com.twitter.hbc.httpclient.ClientBase.establishConnection.184 - Hosebird-Client-01 IOException caught when establishing connection to https://stream.twitter.com/1.1/statuses/filter.json?delimited=length&stall_warnings=true"

Debugging this, under the covers, I see a request to "Connect to stream.twitter.com:80 timed out". How bizzare!

It seems quite coincidental that this is just happening, today, on the day of the switch over. What I can't understand, however, is where the "http" request comes in at all when everything from within hosebird is set up to use https.

26 weeks 4 hours ago

@Al_Sweetman Al Sweetman

Code below: This is what's happening with my "proper" client as well as the test client I just created for a proof-of-concept. Incidentally developed against Hosebird 1.4.0

```
import com.google.common.collect.Lists;
```
```
import com.twitter.hbc.ClientBuilder;
```
```
import com.twitter.hbc.core.Client;
```
```
import com.twitter.hbc.core.Constants;
```
```
import com.twitter.hbc.core.Hosts;
```
```
import com.twitter.hbc.core.HttpHosts;
```

import com.twitter.hbc.core.endpoint.StatusesFilterEndpoint;

import com.twitter.hbc.core.event.Event;

import com.twitter.hbc.core.processor.StringDelimitedProcessor;

import com.twitter.hbc.httpclient.auth.Authentication;

import com.twitter.hbc.httpclient.auth.OAuth1;

```
 
```
```
import java.util.List;
```

import java.util.concurrent.BlockingQueue;

import java.util.concurrent.LinkedBlockingQueue;

```
 
```
```
/
```
```
 * Created with IntelliJ IDEA.
```
```
 */
```
```
public class TwitterTest
```
```
{
```

    public static void main(String[] args )

```
    {
```
```
        String consumerKey = "XXX";
```
```
        String consumerSecret = "XXX";
```
```
        String token = "XXX";
```
```
        String secret = "XXX";
```
```
 
```

        / Set up your blocking queues: Be sure to size these properly based on expected TPS of your stream */

        BlockingQueue<String> msgQueue = new LinkedBlockingQueue<String>( 100000 );

        BlockingQueue<Event> eventQueue = new LinkedBlockingQueue<Event>( 1000 );

```
 
```

/** Declare the host you want to connect to, the endpoint, and authentication (basic auth or oauth) */

        Hosts hosebirdHosts = new HttpHosts( Constants.STREAM_HOST );

        StatusesFilterEndpoint endpoint = new StatusesFilterEndpoint();

        List<String> terms = Lists.newArrayList( "twitter", "api" );

```
        endpoint.trackTerms( terms );
```
```
 
```

        Authentication hosebirdAuth = new OAuth1( consumerKey, consumerSecret, token, secret );

        ClientBuilder builder = new ClientBuilder()

                .name( "Hosebird-Client-01" )                              // optional: mainly for the logs

```
                .hosts( hosebirdHosts )
```

                .authentication( hosebirdAuth )

```
                .endpoint( endpoint )
```

                .processor( new StringDelimitedProcessor( msgQueue ) )

                .eventMessageQueue( eventQueue );                          // optional: use this if you want to process client events

```
 
```

        Client hosebirdClient = builder.build();

```
 
```
```
        hosebirdClient.connect();
```
```
        int count = 0;
```

        while ( !hosebirdClient.isDone() && count++ < 10 )

```
        {
```
```
            String msg = null;
```
```
            try
```
```
            {
```
```
                msg = msgQueue.take();
```
```
            }
```

            catch ( InterruptedException e )

```
            {
```

                e.printStackTrace();  //To change body of catch statement use File | Settings | File Templates.

```
            }
```

            System.out.println( "message  " + msg );

```
        }
```
```
        hosebirdClient.stop();
```
```
    }
```
```
}
```

26 weeks 4 hours ago

@Al_Sweetman Al Sweetman

Investigations reveal that there is a bug in RestartableHttpClient which I'm going to try to write a patch for whereby it doesn't respect the https scheme if it's present when constructing HttpHost instances.

26 weeks 3 hours ago

@lfcipriani Luis Cipriani

Indeed, this is not a problem related to this change. Glad that you found the bug.

26 weeks 3 hours ago

@Al_Sweetman Al Sweetman

Well, it is kind of related? To quote: "If your application still uses HTTP plaintext connections you will need to update it to use HTTPS connections, otherwise your app will stop functioning. "

From what I can see, the http://stream.twitter.com/1.1 has now been "turned off" as part of this change, hence causing all instances of hosebird to fail? This is hosebird that fails, rather than our individual application.

25 weeks 6 days ago

@bartwegrzyn Bart Wegrzyn

Having the same issue. HBC tries to connect to a non HTTPS endpoint.

org.apache.http.conn.ConnectTimeoutException: Connect to stream.twitter.com:80 timed out

Any updates on how to fix this?

Update: For anyone else trying to debug this... it turns out the com.amazonaws:aws-java-sdk requires version 4.2 of org.apache.httpcomponents:httpclient, which has a bug that doesn't respect the scheme of a URL when using DecompressingHttpClient. This issue was fixed in 4.2.1, see https://issues.apache.org/jira/browse/HTTPCLIENT-1200.

I had to exclude the old dependency on com.amazonaws:aws-java-sdk and let com.twitter:hbc-core use its newer dependency.

25 weeks 4 days ago

@lfcipriani Luis Cipriani

The change was deployed at 17:25 UTC (Jan 14, 2014)

26 weeks 2 hours ago

@pgarvie Paul Garvie

Thanks Luis. Nice job!!

PaulG

26 weeks 1 hour ago

@Catfe_LA Catfe

Thanks!

19 weeks 4 days ago

@followfever_com FollowFever

I get the same troubles that one week ago (during several hours). I do not know what is wrong...

25 weeks 6 days ago

Restricting api.twitter.com to SSL/TLS traffic

Replies

Related content

Tags