GIANT Stories at MongoDB

Every database on the planet is a time-series database

If you can store an integer and a value you have a time-series data store. Every database on the planet can support a time-series workload so what sets MongoDB apart? A flexible document model, transactional consistency, horizontal scaling, native datetime support, real-time analytics and visualizations, and millions of users worldwide to name a few.

MongoDB Atlas: Connector for Apache Spark now Officially Certified for Azure Databricks

We are happy to announce that the MongoDB Connector for Apache Spark is now officially certified for Microsoft Azure Databricks. MongoDB Atlas users can integrate Spark and MongoDB in the cloud for advanced analytics and machine learning workloads by using the MongoDB Connector for Apache Spark which is fully supported and maintained by MongoDB.

The MongoDB Connector for Apache Spark exposes all of Spark’s libraries, including Scala, Java, Python, and R. MongoDB data is materialized as DataFrames and Datasets for analysis with machine learning, graph, streaming, and SQL APIs. The MongoDB Connector for Apache Spark can take advantage of MongoDB’s aggregation pipeline and rich secondary indexes to extract, filter, and process only the range of data it needs – for example, analyzing all customers located in a specific geography. This is very different from simple NoSQL data stores that do not offer secondary indexes or in-database aggregations and require the extraction of all data based on a simple primary key, even if only a subset of that data is needed for the Spark process. This results in more processing overhead, more hardware, and longer time-to-insight for data scientists and engineers.

Additionally, MongoDB’s workload isolation makes it easy for users to efficiently process data drawn from multiple sources into a single database with zero impact on other business-critical database operations. Running Spark on MongoDB reduces operational overhead as well. Running Spark jobs on MongoDB eliminates the need to ETL duplicate data to a separate cluster of HDFS servers, greatly simplifying your architecture and increasing the speed at which analytics can be executed.

MongoDB Atlas, our on-demand, fully-managed cloud database service for MongoDB, makes it even easier to run sophisticated analytics processing by eliminating the operational overhead of managing database clusters directly. By combining Azure Databricks and MongoDB, Atlas users can make benefit of a fully managed analytics platform, freeing engineering resources to focus on their core business domain and deliver actionable insights quickly.

What's Next?

Working with MongoDB Transactions with C# and the .NET Framework

MongoDB .NET Drivers versions 2.7 and above support MongoDB Transactions. While MongoDB has always had transactional consistency at the document level, broader cross collection transactional support is now available with MongoDB version 4.0 In this blog post we will take a first look at using MongoDB Transactions within your C# code.

MongoDB now released under the Server Side Public License

Eliot Horowitz

Company

MongoDB has created a new software license called the Server Side Public License, or SSPL. The SSPL clarifies the conditions for making MongoDB publicly available as a service, to ensure we can continue to invest in building MongoDB for our users rather than in costly litigation over enforcing the AGPL. All subsequent versions and patch releases to prior versions of MongoDB made after October 16th, 2018 will be issued under the new SSPL.

Software as a service is one of the most significant and far-reaching paradigm shifts the technology industry has ever seen, and the market is moving to adopt it rapidly. This change is motivated by one simple truth: it is inefficient to operate software at scale when you just want to make use of its capabilities.

This should be a time of incredible opportunity for open source. The revenue generated by a service can be a great source of funding for open source projects, far greater than what has historically been available. The reality, however, is that once an open source project becomes interesting, it is too easy for large cloud vendors to capture most of the value while contributing little or nothing back to the community. As a result, smaller companies are understandably unwilling to wager their existence against the strategic interests of the large cloud vendors, and most new software is being written as closed source.

The best current solution for an open source company is to license their software under the AGPL, which requires a management stack used to operate that software as a service to be made available under the terms of the AGPL. This approach was believed to be good enough, as most people understood their obligations to comply with AGPL. However, as AGPL-licensed software like MongoDB has become more popular, organizations like the international cloud providers have begun to test the boundaries of this license. We would prefer to avoid litigation to defend the AGPL but instead devote our time to build great products for the community and our customers.

Since we own 100% of the copyright of MongoDB, one option available to us was to convert our open source license to a closed source license. We chose not to because we fundamentally believe in open source software. We believe an open source approach leads to more valuable, robust, and secure software, and it directly enables a stronger community and better products. We also could have licensed most of the code for the MongoDB server as AGPL while applying a closed license to some critical files. We chose not to do that because we believe that a uniform licensing approach, where all the code in a repository shares a single license, makes it easier to understand the obligations of using that code, leading to a stronger development community.

The community needs an updated open source license that builds on the spirit of the AGPL, but makes explicit the conditions for providing the licensed software as a service.

The SSPL is designed to make sure that companies who do run a publicly available MongoDB (or any software subject to the SSPL) as a service are giving back to the community.

It should be noted that the new license maintains all of the same freedoms the community has always had with MongoDB under the AGPL - they are free to use, review, modify, and redistribute the source code. We based the SSPL on GPL v3, with one new section that sets out an explicit condition for offering the licensed software as a service. We believe that the SSPL meets the standards for an open source license and are working to have it approved by the OSI.

Obviously, this new license helps our business, and that is one of the primary reasons we made this decision, but it is also critical for the MongoDB community. Over the past decade MongoDB has invested approximately $300M in research and development to offer an open source database to everyone, and this change protects our ability to invest aggressively in R&D to drive further innovation and value for the community.

I am convinced that the SSPL will have a positive effect on the open source community by encouraging increased investment into open source server-side software. As always, we are listening closely for your feedback, and we are eager to work with the community to drive towards a more open future.

Resources

MongoDB On The Road - Node+JS Interactive

October 10-12, 2018 brought 1,000 developers to Vancouver, BC, Canada for the Node+JS Interactive 2018 conference. Put on by The Linux Foundation, the conference provided talks for two days followed by a day of workshops. MongoDB was a proud Bronze Sponsor of the event. This allowed us to have a booth in the Sponsor Showcase Hall along with having a presence at the Career Fair event.

Sponsor Hall

MongoDB had a great presence at Node+JS Interactive 2018. Aydrian Howard and I from the Developer Advocacy team were on hand to answer questions. Thomas Cirri was there from our Recruiting team. By the way, we’re hiring! Dan Aprahamian from our Node.js Driver team was there along with Gregg Brewster from MongoDB University.

Aydrian Howard (left) and Thomas Cirri

The Sponsor Showcase Hall was filled most of the day with people learning about all aspects of the Node.js ecosystem. The MongoDB booth was busy handing out swag and answering questions about MongoDB Atlas, MongoDB Stitch, MongoDB Charts, along with many other subjects and topics.

On Thursday, MongoDB held a drawing for a BB-8 Droid give-away which was won by Eduardo Trindade, System Analyst at A&W.

Eduardo Trindade showing off his new BB-8 Droid prize.

Node+JS Interactive 2018 Sessions

The schedule of session talks brought a wide variety of topics and speakers to Vancouver. Irina Shestak from MongoDB gave a great talk on HTTP/2 walking through the connection process one frame at a time and giving special attention to how Node.js implements this protocol.

Irina Shestak (MongoDB) giving her talk on HTTP/2, One Frame At A Time

Jenna Zeigen’s talk From Parentheses to Perception: How Your Code Becomes Someone Else's Reality provided some wonderful information on the path from an idea in a developer’s mind, to pixels on the screen.

Jenna Zeigen (Slack) giving a talk on From Parentheses to Perception: How Your Code Becomes Someone Else's Reality

There were many other talks from great speakers such as Tierney Cyren from NodeSource, Joe Karlsson from Best Buy, and Adam Baldwin from npm, just to name a few.

Node+JS Interactive 2018 Venue

Node+JS Interactive was hosted by the Vancouver Convention Center - West. Located in the West End area of Vancouver, it overlooks Vancouver Harbor and sits adjacent to the Olympic Cauldron at Jack Poole Plaza.

Vancouver Convention Center - West
North Facing View from the Sponsor Showcase Hall
The Olympic Flame Cauldron from the 2010 Winter Olympics

Vancouver Harbour is not only a busy cargo port bringing in goods for Western Canada, but it is also a heavily trafficked float plane area with seaplanes taking off and landing throughout the day. It was quite a site to be in a conference center and looking out over the harbor’s spectacular scenery and seeing the seaplanes land, taxi, and take off in the crisp and clear fall air.

de Havilland Canada DHC-2 Beaver Seaplane landing in Vancouver Harbour

Conclusion

Node.js works incredibly well with MongoDB. They’re both parts of the popular MEAN/MERN stack. If JavaScript and Node.js are of interest to you, I would highly recommend attending the next Node+JS Interactive event. The Linux Foundation did a great job, and Emily Ruf, in particular, did an amazing job organizing the event. Make sure to stop by the MongoDB booth at future events, pick up some swag, and ask questions. We truly enjoy talking with customers, current and future, about how MongoDB can save time for developers.

If you missed us at Node+JS Interactive 2018 and have questions about MongoDB Atlas, MongoDB Stitch, MongoDB Charts, check them out today. It’s free to get started!

Data Enrichment with MongoDB Stitch

Maxime Beugnet

mongodb

Objectives

Here is what we are going to achieve in this tutorial:

  • Firstly, we are going to write a document to MongoDB using MongoDB Stitch.
  • The result in our MongoDB collection will look like this:

    
    {
    "_id": ObjectId("5bb27712dced5f37bebf388c"),
    "Title":"Guardians of the Galaxy"
    }
    
    
  • Secondly, a trigger will catch this new insertion and start a function.
  • Lastly, this function will call the OMDB external API with the given movie title, fetch data about that movie, and finally enrich our MongoDB document with the data we gathered from this API.
  • This is the final result we expect in our MongoDB collection:

    
    {  
       "_id": ObjectId("5bb27712dced5f37bebf388c"),
       "Title":"Guardians of the Galaxy",
       "Year":"2014",
       "Rated":"PG-13",
       "Released":"01 Aug 2014",
       "Runtime":"121 min",
       "Genre":"Action, Adventure, Comedy",
       "Director":"James Gunn",
       "Writer":"James Gunn, Nicole Perlman, Dan Abnett (based on the Marvel comics by), Andy Lanning (based on the Marvel comics by), Bill Mantlo (character created by: Rocket Raccoon), Keith Giffen (character created by: Rocket Raccoon), Jim Starlin (characters created by: Drax the Destroyer,  Gamora & Thanos), Steve Englehart (character created by: Star-Lord), Steve Gan (character created by: Star-Lord), Steve Gerber (character created by: Howard the Duck), Val Mayerik (character created by: Howard the Duck)",
       "Actors":"Chris Pratt, Zoe Saldana, Dave Bautista, Vin Diesel",
       "Plot":"A group of intergalactic criminals are forced to work together to stop a fanatical warrior from taking control of the universe.",
       "Language":"English",
       "Country":"USA",
       "Awards":"Nominated for 2 Oscars. Another 52 wins & 99 nominations.",
       "Poster":"https://m.media-amazon.com/images/M/MV5BMTAwMjU5OTgxNjZeQTJeQWpwZ15BbWU4MDUxNDYxODEx._V1_SX300.jpg",
       "Ratings":[  
          {  
             "Source":"Internet Movie Database",
             "Value":"8.1/10"
          },
          {  
             "Source":"Rotten Tomatoes",
             "Value":"91%"
          },
          {  
             "Source":"Metacritic",
             "Value":"76/100"
          }
       ],
       "Metascore":"76",
       "imdbRating":"8.1",
       "imdbVotes":"871,949",
       "imdbID":"tt2015381",
       "Type":"movie",
       "DVD":"09 Dec 2014",
       "BoxOffice":"$270,592,504",
       "Production":"Walt Disney Pictures",
       "Website":"http://marvel.com/guardians",
       "Response":"True"
    }
    
    

    Prerequisites

    So first of all, if you want to try this at home, it is very easy. The only requirement here is to create a free MongoDB Atlas cluster. This video will show you the steps.

    MongoDB Stitch is our serverless platform, built by MongoDB on top of MongoDB Atlas. Once our MongoDB Atlas cluster is ready to use, link a MongoDB Stitch application to it:

    • Click on the left panel on “Stitch Apps”,
    • Then click on “Create New Application”,
    • Pick the name you want for your application,
    • Link it to your free MongoDB Atlas cluster.

    Actions

    To be able to send a document to MongoDB, we are going to use an HTTP POST service.

    • On the left panel, click on “Services”,
    • Then click on “Add a Service”,
    • Choose a service name “IMDB”,
    • Note: “IMDB” will be reuse later in the function code. If you choose another name, please make sure to update the code accordingly.
    • Click on “Add Service”,
    • Click on “Add Incoming Webhook”,
    • And copy the screenshot below.

    When this is done, hit the “Save” button and you will be in the “Function Editor” screen.

    • Enter the following code:
    • 
      exports = function(payload, response) {
        const mongodb = context.services.get("mongodb-atlas");
        const movies = mongodb.db("stitch").collection("movies");
        var body = EJSON.parse(payload.body.text());
        movies.insertOne(body)
        .then(result => {
          response.setStatusCode(201);
        });
      };
      
      
    • Click the “Save” button again.

    Now that our Service is ready, we can test it!

    • Go to the “Settings” and you will find your Webhook URL.
    • You can now send an HTTP POST request like this to MongoDB Stitch:
    • 
      curl -H "Content-Type: application/json" -d '{"Title":"Guardians of the Galaxy"}' https://webhooks.mongodb-stitch.com/api/client/v2.0/app/stitchtapp-abcde/service/IMDB/incoming_webhook/post_movie_title?secret=test
      
      
      Note: I used a curl command but feel free to use Postman or whatever you are used to.
    • We can check it worked by having a look at the content of the “stitch.movies” collection in our MongoDB Atlas Cluster:

    Now that we can insert a new document into MongoDB Atlas using Stitch, we are going to create the trigger.

    • On the left panel click on “Triggers”,
    • Then click on “Add a Database Trigger”,
    • And do as follow.
    • This is the code you will need to create the new function:
    • 
      exports = function(changeEvent) {
        var docId = changeEvent.documentKey._id;
        var title = encodeURIComponent(changeEvent.fullDocument.Title.trim());
      
        var movies = context.services.get("mongodb-atlas").db("stitch").collection("movies");
        var imdb_url = "http://www.omdbapi.com/?apikey=a12b1234&t=" + title;
      
        const http = context.services.get("IMDB"); // change the name of the service here if you used a different name.
          return http
            .get({ url: imdb_url })
            .then(resp => {
              var doc = EJSON.parse(resp.body.text());
              movies.updateOne({"_id":docId}, doc);
              });
      };
      
      
    • As you can see in the middle of the code, I am using the OMDB API and I replaced the API key with a fake one.
    • You can create your own free API Key here with just a valid email address: http://www.omdbapi.com/apikey.aspx - limited to 1000 calls per day.
    • Once this is done, you can just replace my fake API key (highlighted in yellow) with your own key.

    Now that this is ready, we just have to test it by repeating the same CURL command we used before. Feel free to use another movie title if you have a better one in mind ;-).

    I removed the previous test we made before adding the trigger and now this is what I have in my collection:

    Let’s review for a second what we have done:

    • We inserted a new document using an HTTP POST service hosted by MongoDB Stitch containing only an “_id” (automatically populated by MongoDB) and a “Title”.
    • The insertion of this document is detected by the trigger that calls an external Web API using this “Title” as the parameter.
    • We are then parsing the body of the result we get from this API and updating the document we inserted a few milliseconds ago.

    Conclusion

    With just a few lines of code, you can enrich the data where it lives with MongoDB Stitch. This is a great way to leverage your micro services architecture and finally switch to an event-driven architecture.

    Next Steps

    Thanks for taking the time to read my post. I hope you found it useful and interesting.

    If MongoDB Stitch is something you are considering in production, you can discover here how the billing works.

    If you want to query your data sitting in MongoDB Atlas using MongoDB Stitch, I recommend this article from Michael Lynn.

Working with MongoDB Stitch Through Existing Drivers – Python & PyMongo

Andrew Morgan

Technical, Cloud

You can now access MongoDB Stitch (and Atlas behind it) using any of the existing MongoDB Drivers – this post shows how to do it using the PyMongo Python Driver.

Exciting New Security Features in MongoDB 4.0

We would like in this blog post to highlight two of the most important security enhancements delivered in MongoDB version 4.0: SHA-256 support and TLS improvements.

The General Availability of 4.0 was announced on June 27, 2018 at MongoDB World 2018. Its multi-document ACID transactions, new native type conversions, Kubernetes integration, as well as new tooling and cloud services, make it our most significant release ever!

Now we hope to provide some context and history to explain why the new security features matter and offer you some technical information to help everyone take advantage of them with MongoDB 4.0

SCRAM-SHA-256 “Bigger is Better”

Many people have been asking about what MongoDB is doing regarding the rare and interesting SHA-1 vulnerability--and we’re happy to say that we’ve addressed these concerns in MongoDB 4.0 with support for SHA-256.

Secure Hash Algorithm (SHA) is a hash function used to help ensure data is not modified, by assigning a unique signature to a piece of data. SHA does this by computing a cryptographic value (hash) that both can be quickly generated and also be unique enough that it is not feasible to predict. The algorithm used for this computation is determined by the version of SHA used, which directly affects core hash function properties: speed and uniqueness.

A hash function is considered successful when different data provided to it yields completely unique hash values, such that any change to the data results in a change to the hash values. Comparing hash values thus can be used to reliably check whether your data has been tampered with.

A hash function is considered a failure when different data provided to it yields the exact same resulting hash values. This is called a “collision”, and it means that the function does not achieve the primary goal of uniqueness and, in effect, a signature can be forged.

NIST, for example, had in 2011 begun warning against SHA-1 failure in its Special Publication 800-131A: "SHA-1 shall not be used for digital signature generation after December 31, 2013”.

Hash Function Use
SHA-1 Digital Signature Generation Disallowed (except where specified by NIST protocol-specific guidance)
Digital Signature Verification Legacy Use
Non-digital Signature Acceptable
SHA-2 family (SHA-224, SHA-256, SHA-384, SHA-512, SHA-512/224, SHA-512/256) Acceptable for all hash function applications
SHA-3 family (SHA3-224, SHA3-256, SHA3-384, SHA3-512) Acceptable for all hash function applications

Then in 2012 Intel researcher Jesse Walker famously predicted the cost of performing a collision attack on SHA-1 would be “within the range of organized crime” by 2018, and affordable for university researchers by 2021. This set off a series of recommendations by cryptographers about the need to move to a newer version of SHA.

By 2015 a “Logjam” attack led OpenSSH to recommend discontinuing use of the diffie-hellman-group1-sha1 key exchange algorithm, prompting a move to later groups with a fixed prime for SHA-1.

Walker’s economics prediction by 2017 still looked fairly accurate as news reports titled “The SHA1 hash function is now completely unsafe” were in the mainstream press. Two different PDF files had been created with the same SHA-1 signature (“shattered.it”).

The required attack resources remained very high at this point, despite university research in 2015 to improve attacks, as they reportedly were soaking up “6,500 years of single-CPU computations and 110 years of single-GPU computations” to force a single collision.

Nonetheless, many security experts believed in 2017 a predicted corner had been turned on SHA versions and major browsers began marking SHA-1-signed HTTPS certificates as unsafe.

Naturally at this time customers began asking MongoDB whether SHA-1 was safe to continue using in the secure challenge-response authentication mechanism (SCRAM). This modern authentication mechanism, also known as IETF RFC 5802, had been designed to use any hash function defined by the IANA, and SHA-1 was the first generation that SCRAM deployed.

The SHA-1 crypto primitive weaknesses documented by researchers have not yet impacted such a challenge-response authentication flow, because it relies on quite a bit more than a single iteration of a hashing function. To illustrate better where and how SCRAM uses a hash function, here are the essential steps of authentication:

  1. Client transmits a username for authentication by server
  2. Server responds with a salt for that username and the number of iterations required (either generated or based on a lookup for transmitted usernames)
  3. Client responds with proof that it has a key, without sending the key
  4. Server responds with signature, as its own proof. If a match, client knows server has the right salted password hash

Both server and client are using Password-Based Key Derivation Function 2 (PBKDF2) to prove they have knowledge of a password by passing back and forth a one-time (nonce) random or pseudo-random number and hashes, after undergoing many thousands of hash-based message authentication code (HMAC) iterations of that password. Finding a collision in this context means overcoming many thousands of iterations thanks to PBKDF2 as well as several layers of unique nonce'd HMAC.

Nonetheless, given the above SP 800-131A guidance as well as the precautionary measure recommendations, we’re pleased to announce SCRAM use of SHA-256 is immediately available in the MongoDB 4.0 release.

Assuming that you’ve already enabled SCRAM-SHA-1 in your database instances prior to your upgrade to MongoDB 4.0, an upgrade to SHA-256 is completely automated. Existing users will individually continue to use SHA-1 without issue and will only begin using SHA-256 when you choose to update the given user’s password, while newly created users will automatically use SHA-256 by default.

After you’ve added SHA-256 support for all of your users, then you can optionally disable SHA-1 globally and prevent client use of SHA-1 hashes using the authenticationMechanisms server parameter (note that any accounts which only support the SCRAM-SHA-256 authentication mechanism will no longer be usable if you perform a downgrade from 4.0 for any reason).

(Note: Internal cluster auth, which uses the built-in __system user, will continue to use SCRAM-SHA-1 in 4.0 if you have not specified x509 for the clusterAuthMode. For optimal security and/or to meet any compliance objectives which require the prevention of all SHA-1 hashes, we recommend using x509 authentication for your clusters.)

Once you’ve upgraded to MongoDB 4.0, you will create new users in the same way that you did before. As you can see, the createUser command remains the same:


mongodb> db.createUser( {user:"matt", pwd:"pass", roles:[{role:"root", db:"admin"}]} )
Successfully added user: {
    "user" : "matt",
    "roles" : [
        {
            "role" : "root",
            "db" : "admin"
        }
    ]
}


But if we look at the resulting user that was created, we can see that the account supports both SCRAM-SHA-1 and SCRAM-SHA-256. SCRAM-SHA-1 will only be used as a fallback mechanism if needed -- for example when talking to older clients -- unless we explicitly disable it entirely using the authenticationMechanisms server parameter.


mongodb> db.runCommand({usersInfo: 1})
{
    "users" : [
        {
            "_id" : "admin.matt",
            "user" : "matt",
            "db" : "admin",
            "roles" : [
                {
                    "role" : "root",
                    "db" : "admin"
                }
            ],
            "mechanisms" : [
                "SCRAM-SHA-1",
                "SCRAM-SHA-256"
            ]
        }
    ],
    "ok" : 1
}

For existing users, it’s very simple to add SCRAM-SHA-256 as a supported mechanism. First, you can see an example command which can be used to identify those existing users that don’t yet have SCRAM-SHA-256 support:


mongodb> db.runCommand( {usersInfo:{forAllDBs:true}, filter:{mechanisms:{$ne:"SCRAM-SHA-256"}}} )
{
    "users" : [
        {
            "_id" : "admin.oldmatt",
            "user" : "oldmatt",
            "db" : "admin",
            "roles" : [
                {
                    "role" : "root",
                    "db" : "admin"
                }
            ],
            "mechanisms" : [
                "SCRAM-SHA-1"
            ]
        }
    ],
    "ok" : 1
}

Then once we’ve identified those accounts, we can easily add SCRAM-SHA-256 support simply by re-setting the password for the account:


mongodb> db.updateUser( "oldmatt", {pwd:"pass"} )

Just please be aware:

  1. You need to explicitly specify the user’s password as the SCRAM-SHA-256 credentials need to be generated from that input.
  2. This means that you’ll need to update existing users one by one.
  3. And since the DBA should not know the password for each user, this migration likely needs users to take action. But since the account migration happens automatically when the password is updated, the migration can be done as part of your normal password rotation procedures.

In summary, MongoDB 4.0 ensures that you’re easily able to meet any applicable security requirements and compliance objectives by moving to SHA-256 support in its SCRAM authentication mechanism.

TLS “Onwards and Upwards”

Transport Layer Security (TLS) protocol versions below 1.1 should be disabled and MongoDB 4.0 has taken care of this across the board, for all products on all platforms– TLS 1.0 is disabled by default everywhere, whether you run MongoDB yourself or use our fully automated and on-demand Atlas service.

The Secure Sockets Layer (SSL) protocol is practically a dinosaur in Internet time, going back to the mid-1990s. It had a rough early start -- SSL version 1 and 2 were immediately deprecated -- and after it was first formalized in 1996 it even experienced a name change to Transport Layer Security (TLS). The path to widespread adoption came slowly thanks to an evolutionary process of awareness about the benefits of privacy in network traffic. Yet today it is easy to take for granted that security has been integrated behind the scenes in network communications.

With the Internet increasingly serving as the backbone for so much of modern life, TLS followed a cycle of improvements and in 2008 TLS 1.2 was announced. This version persisted another ten years until just this past March 2018 when TLS 1.3 received formal approval.

Going back to the beginnings of SSL, it was a set of serious security flaws in version 1, 2 and 3 that signaled their demise. The market initially reacted slowly. Even though only browsers made before 1997 needed to run SSL version 2, few providers were proactively removing it. Partly the delay was because regulators did not yet step in on behalf of customers, instead letting service providers self-regulate. For example, in section 4.1 of the Payment Card Industry (PCI) Data Security Standard (DSS) the concept of “safe SSL” was left open to interpretation.

Unfortunately, self-regulation didn’t lead to any progress and so an Assessor Update of November 2008 was dropped with a detailed and strict interpretation. After a series of serious privacy breach investigations, SSLv2 was abruptly prohibited: “it is imperative that an ASV identify the use of SSL 2.0 to transmit cardholder data as a failure”.

This was possible because SSLv3 was widely deployed, as well as the later TLSv1. Nonetheless SSLv2 continued to be difficult to eliminate from the Internet at large, beyond the reach of PCI, as giant service providers and the largest software companies moved slowly to remove deprecated protocol versions. Difficult discussions were had in 2009 given TLS version 1.2 had been formalized and there appeared to be no reason to continue with SSLv2. Microsoft Windows Server product managers, for example, left SSLv2 on as a default in spite of regulators’ best attempts.

Fast forward five years to 2014 and TLS version 1.0 also was found to have serious security flaws such as Padding Oracle On Downgraded Legacy Encryption (POODLE). The PCI regulators, reflecting on the deprecation lessons from SSL, took a firm future position to end use and set a deadline in 2016; again large entities’ requested more time to comply and this deadline soon moderated to 2018. Regulators beyond PCI also chimed in, such as the Internet Engineering Task Force (IETF) itself and the National Institute for Standards in Technology (NIST) who issued strong recommendations about discontinuing TLS versions earlier than 1.1.

When will TLS version 1.1 be deprecated? There are few signs yet that regulators will require TLS version 1.2 as the minimum anytime soon. Best estimates for version 1.1 being banned are based on the RFC timeline above, given a natural cycle the IETF follows, and also the fact that an RFC just was published with the URL “tls-oldversions-diediedie”.

Mozilla only very recently has begun offering TLS 1.3 as an option in their Firefox browser. You can type about:config in Firefox’s address bar and confirm the warning message. Then search for security.tls.version and if you see a 4 instead of a 3, you already have TLS 1.3 support. You also can double-click on 3 (TLS 1.2) and change it to 4 if you want to enable TLS 1.3.

The bottom line is that history repeats and starting in the second half of 2018, many companies are required to comply with network protocol safety requirements issued by NIST, IETF and PCI DSS. This means today that versions earlier than TLSv1.1 should be disabled and MongoDB 4.0 has taken care of this across the board, for all products on all platforms – TLS 1.0 is disabled by default everywhere, whether you run MongoDB yourself or use our fully automated and on-demand Atlasservice.

The next question that users often have is: How can I tell which version of TLS my client application is currently using?

A site such as https://www.howsmyssl.com/ is able to tell you whether an application is running a deprecated and unsafe version of TLS. It is an issue both on client and server side, and safe TLS shouldn't be a problem to negotiate in modern releases of client software.

For example, as long as a Python version is built against an OpenSSL version that supports safe TLS, it should see no impact when TLS 1.0 is disabled. Python's Lib/ssl.py comes with documented warnings and "security considerations" that tell you how to make changes for safe TLS to be a default. Note that it does not warn against TLSv1 yet, but it does set the default to TLSv1.2:

SSL versions 2 and 3 are considered insecure and are therefore dangerous to use. If you want maximum compatibility between clients and servers, it is recommended to use PROTOCOL_TLS_CLIENT or PROTOCOL_TLS_SERVER as the protocol version. SSLv2 and SSLv3 are disabled by default.


>>> client_context = ssl.SSLContext(ssl.PROTOCOL_TLS_CLIENT)
>>> client_context.options |= ssl.OP_NO_TLSv1
>>> client_context.options |= ssl.OP_NO_TLSv1_1

The SSL context created above will only allow TLSv1.2 and later connections to a server (if your client supports it).

Then, to test with Python whether safe TLS has been configured properly, the following PSF recommended test can be used:


$> python -c "import requests; print(requests.get('https://www.howsmyssl.com/a/check', verify=False).json()['tls_version'])"

As another example the following test will reveal the TLS protocol version used when using Node >= version 6:


$> nodejs -e "const https=require('https');https.get('https://www.howsmyssl.com/a/check', function(res){var body='';res.on('data', function(chunk){body+=chunk;});res.on('end',function(){var r=JSON.parse(body);console.log(r.tls_version);});});"

And the following test for Ruby will reveal the TLS protocol version:


$> ruby -ropen-uri -rjson -e "puts JSON.parse(open('https://www.howsmyssl.com/a/check').read)['tls_version']"

Our TLS implementations in the MongoDB Server also now have been integrated with the native crypto libraries available on each platform: OpenSSL on Linux, Secure Channel on Windows, and Secure Transport on OS X. This ensures that MongoDB is current with the latest crypto library available on the OS, for emerging definitions of safety and strength. It allows us also in the future to take advantage of unique OS crypto features such as leveraging Keychain on OS X.

This new TLS usage covers all communication in MongoDB 4.0 -- between the clients, drivers, and server, as well as the internal cluster communication between nodes -- and we’ve implemented all of this in a way that requires no special upgrade/downgrade procedures.

Conclusion

Even if you have no immediate plans to use Transactions or any of the other great new features in MongoDB 4.0, upgrading is highly recommended because by doing so you will be improving the overall security of your MongoDB based applications.

Connecting MongoDB Stitch to Google Places

One of the services that make available a wealth of data via API, is Google Places.

Imagine we want to provide users of our application with information about a business with whom we partner. Insurance companies do this with providers of accommodations, transportation, and healthcare. We don’t want to maintain this information, or own it - rather, we’d prefer to leverage a service that provides this information about these service providers. Google Places is just such a service provider.

For this application, we’ll use the following Stitch components to integrate MongoDB with Google Places.

Stitch Functions

Stitch functions are written in JavaScript ES6 and can be called from our SDKs, Triggers, or Webhooks and are great for coordinating data access or doing light processing alongside a query or insert. Communicating with data provider services such as Google Places is as simple as leveraging an HTTP service within a serverless stitch function:

    
const http = context.services.get("GooglePlaces");
 return http
   .get({url: GooglePlacesSearchURL})
   .then(resp=>{
       //The response body is encoded as raw BSON.Binary. Parse it to JSON.
       var search_result = EJSON.parse(resp.body.text());
    

Stitch’s Functions also let you reference context – such as services, variables, or user information – in order to make it easier to leverage services and information across your entire application. Stitch also provides several third-party services including AWS, Twilio, and Github.

Stitch Services

The HTTP service that we create here will also have an incoming webhook, meaning that it can make outgoing HTTP requests within Stitch Functions, but also handle incoming HTTP services.

Stitch Trigger

Stitch Triggers enable reactivity to inserts, updates, deletes, and replaces that occur in the database. In our case, an insert will trigger execution of a function.

Figure 1. Trigger Configuration

Building Your Application

Let’s take a look at how all the pieces of this application fit together –

Figure 2. Stitch Architectural Diagram
  1. In step 1, an application accepts input either from a user or as a result of some action the user performed (using geofencing, for example.) The input, in our case, will be the name of a business. The application will insert a document with the name of the business into MongoDB.
  2. The firing of the trigger is automatic because we configured it to watch for inserts or updates to our database.
  3. The trigger executes a custom function called getGooglePlaceInfo then captures and forwards the entire inserted document.
  4. Next, in step 4, the function we created invokes the HTTP Webhook we created. The webhook conducts the conversation between Google Places and Stitch.
  5. In step 5, Google Places will respond with a JSON document containing the requested information.

The function will catch this JSON information and update the MongoDB document. It is worth saying that the function can also manipulate the data before inserting it. Allowing it meet all your project requirements (format, types, calculations). As an example, the function may create a new GeoJSON object from the Google coordinates. All of this is done in step 6.

In Conclusion

We’ve taken a very brief look at how leveraging MongoDB Atlas, Stitch, and Triggers in conjunction with a data API service such as Google Places transforms applications into intelligent apps users will truly love to use. Because we’re adding data without having to bother the user, the application becomes much more usable, much more valuable. MongoDB Stitch and Triggers give your application the ability to react to changes in the database. Then leverage integration with external services to fetch in-context data to enrich your applications’ data further. This improves both usability and value to the user.

Without MongoDB Stitch, a developer would have had to contend with building an application server, dealing with management, availability, scalability, and backup and restoration of the data.

Oh, and did we mention that Stitch provides other benefits as well? It leverages Atlas security, adds third-party authentication and granular, field-level access controls to MongoDB data. This gives the ability for users to retrieve data anywhere. Without developers having to create REST APIs from scratch, secure and maintain them?

The content described in this blog article is publically available and can be found here: https://github.com/julienmongodb/mongodb-googleplaces

Make Data-driven Decisions using MongoDB and Looker

Seth Payne

mongodb, Analytics

Today we are announcing a partnership and integration with Looker, a leader in modern, user-friendly business intelligence solutions. Like most BI tools, Looker works well with relational data, so the integration with MongoDB is made possible through the MongoDB Connector for Business Intelligence.

Using a simple, yet highly functional and powerful interface, Looker can ingest data from a number of different data sources empowering business users to create and manage reports and dashboards and make data-driven decisions. Now that MongoDB data can be queried by Looker directly, this removes the need to perform any ETL operations on MongoDB data.

Adding MongoDB as a data source is simple and can be accomplished through Looker’s admin interface for connections. The simplest way to get data into Looker is to use MongoDB Atlas, our DBaaS offering. Alternatively, customers can also connect to on-premises of self-managed instances. Due to MongoDB’s distributed architecture, you can connect to a dedicated secondary replica assigned to analytics and report away without impacting operational workloads running against other nodes in the cluster.

By combining the flexibility of MongoDB, along with Looker’s simple, intuitive, yet powerful interface, business users can quickly and easily gain insights from their MongoDB data. Users can create and manage dashboards, schedule reports, and even share these with colleagues. With Looker and MongoDB, business users can better understand data, identify trends, and make timely decisions based on solid analysis.

To learn more about MongoDB’s integration with Looker, please stop by our booth at Looker JOIN 2018 this week in San Francisco. There you will see hands-on demonstrations of the integration and examples of reports and dashboards that can be created using MongoDB and Looker together.