Custom Domains in Cloud - Our Approach

[#1]

Hi everyone,

Thank you for your engagement on our last update. Based on your feedback, we would like to provide more detail on the following topics:

1. Security considerations underlying custom domains and how they contribute to the two-level domain requirement

2. Support for URL redirects, which will provide more flexibility and address most limitations of the two-level domain

Security considerations underlying custom domains

The security of our customer’s data is always the top priority at Atlassian. When it comes to custom domains, having a two-level domain plays a critical role in making our solution resilient to potential man-in-the-middle (MITM) attacks.

Atlassian’s platform is designed to be open and allow all Atlassian accounts to collaborate across our products and the organizations using them. Therefore, our approach to custom domains needed to be secure, while supporting our multi-tenant SaaS architecture and global user accounts. This means we prioritized capabilities to detect, contain, and control individual user authentication sessions. By detecting threats using a more “prescriptive” URL structure, including reserved keywords, we fortify our threat detection efforts.

We understand the concerns about the convenience tradeoff of the two-level domain requirement, but security of customer data is our highest priority.

Support for URL redirects

To ensure customers have full flexibility, we support URL redirects, which allow you to create links with a shorter, fully customizable base URL. In this case, you can utilize a redirect to redirect your users to the secure URL.

	Description	Example
Short URL (URL Redirect)	The link your customers will visit, the one you will use in marketing material for your Help Center.	https://support.acme.com
Secure URL (Custom domains)	The link your customers will see in their browser after they arrive.	https://secure.support.acme.com

Thank you for your patience and partnership. We continue to look for ways to improve Atlassian admin and end user usability without compromising security.

Stay tuned as we prepare to begin our early access program for custom domains. We remain on track for delivery this year.

Luke 

[Boris Berenberg - Modus Create]

Can you clarify what specific MITM attack scenarios you're trying to mitigate?  

[Adrian Smith]

The security of our users is our highest priority. Redirecting to a different URL is a red flag and should not be something we train our users to find acceptable. https://stillsecure.acme.com

https://secure.support.acme.com is not more secure than https://support.acme.com

This is not a matter of convenience. This is a matter of usability. We can do a redirect now via hundreds of third-party or internal redirection setups.

The limitation of approved keywords is out of touch with the real world uses of your product and does not align with customer expectations.

[Alex Cumberland]

I am wondering the same thing as @Adrian Smith ... how is one https more secure over another https ???

Also if this is the big solution that has taken a decade to come up with then why would we be so vocal about the situation if all we had to do was set up a cloud account and use redirect via any one of the third-party or internal redirection setups.   All you are doing is coming with what we could already do but you are adding another domain level.   So really what is the point ??

[Luke Liu]

@Boris Berenberg - Modus Create Supporting custom domains introduces third-party traffic controls between users and Atlassian servers. A malicious admin could potentially phish for a user's authentication token and use it to access all products and contents that the global user account has access to. 

@Adrian Smith The URL is more secure as it narrows the scope of threat detection, so that the system could detect potential threats (such as invalid certificate) quickly and accurately, and auto initiate containment and controls. We continue to look for ways to enhance the system performance but for the current release we opted to introduce these experience constraints. 

[patrickheinzelmann]

If we wanted to use a redirect for custom domains, we would not need to wait till Atlassian has implemented it. It's like using a url shorten.

The short domain is also not used in the emails notifications, etc.

The urls based on the custom domains (server oder data center version) are shared across organisations and customers, the user experience isn't great if you're simply redirected. This means that you have to communicate that the users was redirected to new domain. You have to have a banner to communicate the behaviour. No, thanks!

The solutions with secure domain looks like a shortcut to simplify the logging and monitoring by only tracking requests based the keywords. With such well-known keywords and this monitoring behaviour, you open the door for more misuse than if have a proper monitoring. This seems to me more insecure than a proper monitoring.

Overall the value of this combination of redirect + custom domain solution is quite limited.

[Adrian Smith]

@Luke Liu If this method is needed for appropriate detection of invalid certificates, you may want to update your method for detecting invalid certificates.

[Boris Berenberg - Modus Create]

I am not sure I understand how a reserved keyword in the domain will impact the admins ability to phish or not phish a user.

Can Atlassian point to any known or documented attack on any other SaaS product that this mechanism explicitly prevents?

Can Atlassian point to any other SaaS product which has implemented this restriction?

[Scion]

Still nothing about custom http root paths such as /jira with any number of subdomains.

I do not see how having more subdomain keywords makes it easier to detect certificate forgery. If the certificate is different, it is different, the number of subdomains is irrelevant.

If you want to prevent against a malicious administrator, you could either sell a DNS service the user must point to, not allow one or zero level subdomains if the instances have any global accounts associated with them (aside from the creator), lock the instance if the server detects any DNS change at all, or simply allow companies to make their own risk management decisions.

[Nicolas Esteves]

I am still not convinced by this explanation. How do other Cloud providers that allow what we all want here do? Aren't they secure? Do you mean limited subdomains is now the new best security practice? Something is wrong here IMHO... 

[David at David Simpson Apps]

🤷‍♂️

[Alex Cumberland]

It almost sounds to me like someone in Marketing came up with the idea that more words in the URL must mean that we can charge more right ?

[Cael Metcalfe]

Is there a possibility that this "solution" is actually intended to deter their customers from using it so that Atlassian's domain will remain in an end user's address bar?

[flaccid]

@Luke Liu please provide some transparency to your customers with specifics on the claim of potential MITM attacks. If it is a critical role as you state, don't you think people deserve an explanation?

We all waited a long time to get this update and as usual it is sub-standard.

btw, the hostname in the 'secure URL' is a 4LD.

[Remie Bolte]

Hej Atlassian,

Using a 1st level custom domain is a widespread industry best practice, and an enterprise feature offered by almost every SaaS vendor. If you are going to challenge that with the claim that this is an insecure practice, you better be able to produce credible evidence of that claim.

Where is the research paper listing how this industry practice should be voided? Where are the talks on conferences, the peer reviews by other major vendors, the discussion groups, the acknowledgments of your breakthrough discovery?

Either you produce evidence, or you should stop bullshitting your customers by making a fool of yourself in front of an entire industry.

[Aniceto Goñi Díaz de Cerio]

OK we're out. 

That's all nonsense. Bullshit. Rubbish. How come a fixed subdomain is safer than a user-chosen subdomain?? How come big companies fully support customer's domains without restrictions and you don't?? How come a redirection is safer than a direct access to the site!!!

You're making weird statements about security, MITM attacks and apocalypse, and providing no evidence or even explaining what you're trying to avoid. Invalid certificates? Don't you know how to detect a valid certificate? If I can forge a fool.company.com certificate, I guess I might be able to forge a fool.support.company.com certificate. Even more, I can forge a redirect.company.com certificate and rule the world!!

Please stop fooling us and implement what we customers need and asked for.

All the rest is rubbish.

If you don't have the ability to implement this, or if the initial arquitecture of the app is not suitable for this (which, in the end, I think it is where all this issue boils down to), just acknowledge it, we'll take no revenge, but please stop this nonsense.

[Jahaziel Calderon]

I don't know Rick, it seems fake

[Wesley Caldwell]

I was upset about this before, but this response was a total slap in the face. 

My first thought when reading this was the same as Aniceto's. We're out.

I didn't want to go through the trouble of moving but I really don't want to support a company like this. 

I think this community has shown a lot of patience and probably would have responded a lot better to a hard truths than to have lies like this presented as fact. 

[Wesley Caldwell]

And this update comes a month and a half after the below update that was on April 4. I think these guys are messing with us. The above is another whole article giving no new information. 

Update Apr 4

To reiterate an earlier comment, thank you all for your engagement and feedback.  We know how important it is for you to have a clear and detailed understanding of the technical reasons behind the constraints and how they enhance your security experience with custom domains. We will come back with a separate update addressing this soon, and will provide more details on the optional URL redirect feature.

[Craig Castle-Mead]

@Luke Liu  - I’m with everybody else on this thread. Your response here shows you’ve blatantly ignored all the customer feedback (“Don’t F*** the customer”, yeah?) and tried to justify why with some un-quantified BS that doesn’t seem to be an issue for any other SaaS vendor on the market that supports exactly what your customer base is expecting Atlassian to deliver on.

Back up your statement with peer validated reasoning, or, build what we’ve been waiting for for 11 years (and your marketing team put up on a slide as “coming soon” at Barcelona summit in 2017 or 2018…)

CCM 

[Dave Meyer]

Hi everyone,

Thank you, as always, for your candid feedback. We truly do value it.

As the Head of Product for our enterprise cloud product development, I stand by both our implementation approach for custom domains and our communications around it.

On the implementation: we believe the current approach meets the needs and provides value to a large number of customers looking for a custom domains solution and offers a level of customization that very few SaaS collaboration products match. We're intentional about balancing security, customization, and the open collaboration that makes Atlassian products unique.

On the communication: I believe one would be be hard-pressed to find a single feature for Atlassian where we have provided more frequent and regular updates over the last two years than custom domains. Between Community posts and updates on the jira.atlassian.com ticket, we are making a good-faith effort to be transparent about security risks without being irresponsible. We also attempt to provide clear and concise updates while still communicating valuable details.

Finally, comments that cross the line into personal criticism of Atlassian staff will not be tolerated. This has no place in our community.

Dave

[Jahaziel Calderon]

Are you planning to change jira.atlassian.com to something like jira.support.atlassian.com? Or are you imposing this unnecessary change on your customers?

[Dave Meyer]

@Jahaziel Calderon this is an optional new feature. No customer will be required to change anything.

Currently, Atlassian cloud product URLs take the form of subdomain.atlassian.net where the subdomain is selected by the customer.

When custom domains are available, customers will be able to configure a URL for their cloud product of the form subdomain.keyword.rooturl.tld, where the subodomain, rooturl, and tld (top-level domain) are all completely customizable and the keyword is chosen from a list of options from Atlassian.

[jvdmr]

@Luke Liu you almost had me! Yes, if a malicious admin sets up a way to phish for user accounts they get credentials to access other Atlassian products from other companies. That's a dangerous thing you should definitely protect against.

However, first and foremost, this shows what a terrible idea the Global User Account system is. It's no inconvenience to anyone to create a new account for every Jira instance they need to access. In fact, I think a lot of your customers don't even want to allow just anyone to access their Jira, they only want their own employees on it, with their corporate email, not a personal account. Global User Accounts are a serious threat to you applications' security. You've backed yourself into a corner with it, and now you think custom domains are the security issue to solve when it's really this.

Secondly, what's to stop anyone from creating a fake Jira login page, host it at any domain at all, and phish for credentials? This is simply not something you can protect against in this way. Implement the industry standard protections against phishing if you haven't already, and stop fooling yourself into thinking that this will stop anything at all.

[Wesley Caldwell]

@Dave Meyer  No wonder this project is so botched. You missed the point @Jahaziel Calderon was making. 

Are you going to be applying this same terrible structure to your own URL's that you are forcing on anyone who wants a custom domain.

so jira.atlassian.com will now be jira.letsmakethislonger.atlassian.com

This is extremely embarrassing for Atlassian and i'm so glad I don't have to put my name on something like this.

[Wesley Caldwell]

Extracted from your comment above:

On the communication: I believe one would be be hard-pressed to find a single feature for Atlassian where we have provided more frequent and regular updates over the last two years than

The bigger question here is why after all these years, you still needed two years of "providing updates" that offer very little information and upset the user base with the bit of information that is given.