Closed Bug 1296375 Opened 9 years ago Closed 9 years ago

Domain request for Campaigns (TBD)

Categories

(Infrastructure & Operations :: SSL Certificates, task)

Product:
Infrastructure & Operations
Component:
SSL Certificates
Type:
task
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED FIXED

People

(Reporter: doliver, Assigned: fox2mike)

Details

(Whiteboard: [kanban:https://webops.kanbanize.com/ctrl_board/2/3320])

We are planning to use this subdomain for marketing pages created at Unbounce. Can we point it to "unbouncepages.com"?
We could do so. I tested their SSL first, to see if it's ready, and but looks like SSL isn't configured at unbouncepages.com yet, so https://campaigns.mozilla.com/ will return SSL errors. Is that something that would be resolved before the site is launched? $ dhost unbouncepages.com name: unbouncepages.com ip_address: 52.9.30.153 ... $ curl -v --resolve 'campaigns.mozilla.com:443:54.193.90.219' https://campaigns.mozilla.com/ * Hostname campaigns.mozilla.com was found in DNS cache * Trying 54.193.90.219... * Connected to campaigns.mozilla.com (54.193.90.219) port 443 (#0) * SSL certificate problem: Invalid certificate chain
I agree with :atoll that this should probably be fixed prior to launch.
It does look like they *expect* it to work: http://documentation.unbounce.com/hc/en-us/articles/204756634-Securing-Your-Landing-Page-Domain-with-SSL-PRO- I had a quick chat with a support rep about it. He said that SSL is only available once you have connected your custom domain: "We will issue an SSL certificate for the domain and it will certainly work."
Heh. Okay. They'll have to get our (Webops/Hostmaster) approval to issue that SSL certificate, and I can't find out which issuer they're using, so hopefully it's one that's trusted in the browsers. :April, can we get an Infosec go/no-go on this? I don't recognize the third party and this is a sub.mozilla.com CNAME, so there might be more work to do before we ship the CNAME.
Flags: needinfo?(april)
I sent a note to them to see if I can get more info about the issuer, will follow up when I hear back.
Yep, that should be fine. If they're doing a DV cert, they should only need the CNAME to request the cert.
Flags: needinfo?(april)
Alright. I've put the CNAME into place. It'll take half an hour to go out. :doliver, please confirm when it resolves for you!
Status: NEW → RESOLVED
Closed: 9 years ago
Flags: needinfo?(doliver)
Resolution: --- → FIXED
Looks like April is correct: "We use a company called GlobalSign (https://www.globalsign.com/en/) to provision SSL certificates for our customers. We only offer DV type certificates, this means that the certificate is provisioned based on the domain. GlobalSign verifies the ownership of the domain via the CNAME record that is set up to point to unbouncepages.com.: -- HTTP traffic is resolving now and the status at Unbounce says they are currently provisioning SSL. Leaving my needinfo in place and I'll comment again when that is working too. Thanks for your help!
The SSL config is not yet complete -- I'm heading out on PTO so Mahe will take over the watch from here and comment when it's complete.
Flags: needinfo?(doliver) → needinfo?(mpotharaju)
Checked one last time and SSL is now in place and working. April & Richard, thanks again for the quick turnaround!
Flags: needinfo?(mpotharaju)
We like to get all .mozilla.org/com sites complying with our web security policy: https://wiki.mozilla.org/Security/Guidelines/Web_Security I'd be happy to work with them towards improving their Mozilla Observatory grade to a B: https://observatory.mozilla.org/analyze.html?host=campaigns.mozilla.com Should they require any assistance. If you could have them take a look at things once we start getting content going, that would be great. Certain things (such as HSTS) and http -> https redirections can probably be worked on now. Thanks so much!
Dylan: Why does this need to be run under a *.mozilla.com domain, as opposed to under an unbouncepages.com domain? This is a security concern, because any code we put under *.mozilla.com can set or read cookies for other sites in that scope. So as a general rule, we shouldn't put code in that scope that we don't control (and have audited / verified /etc.).
Flags: needinfo?(doliver)
Transferring n-i? to Faramarz, since Dylan seems to be PTO.
Flags: needinfo?(doliver) → needinfo?(faramarz)
:faramarz, just FYI, we need to get these web security things fixed before we can go live. Let me know if you need a new bug for them, or if you want to piggyback on this bug.
(In reply to Richard Barnes [:rbarnes] from comment #12) > This is a security concern, because any code we put under *.mozilla.com can > set or read cookies for other sites in that scope. We have so many unrelated sites that we should FORBID our sites from setting global .mozilla.org and .mozilla.com domain cookies as a security policy (if we don't already). Then, at least, they couldn't -read- any important cookies, though a rogue/hacked site could still set some cookies in a session-fixation or tracking attempt. We seem to do pretty good on that score although in the past I'd see some analytics type cookies creep into that namespace. Come to think of it, though, I use tracking protection so maybe I'm just blocking those scripts. > So as a general rule, we shouldn't put code in that scope that we don't > control (and have audited / verified /etc.). I can't fault the rule (webmaker.org was better than learning.mozilla.org) but you'll be fighting the whole marketing/content org on that, and our CEO came from the marketing side.
adding Porfirio for Marketing perspective.
Flags: needinfo?(faramarz)
Thanks for the add... Marketing/brand is trying to avoid the creation/use of new TLDs, so we were fine with an Unbounce sub-domain (mozilla.unbounce.com, mozilla-campaigns.unbounce.com, etc.), but this was flagged for a security concern, I believe. Hence, we landed on the suggestion of a subdomain of Mozilla instead. I could recommend a new TLD for these tests in general, like mozilla-campaigns.org/com. Would that work? We'd also want to make sure that root is not search indexed, and have each project at their own sub-directory: mozilla-campaigns.org/haiku mozilla-campaigns.org/smartkitchen mozilla-campaigns.org/etc
Hmm, can you point at the security concerns that mozilla.unbounce.com was flagged for? Overall, I prefer non-mozilla domains (mozilla-compaigns.org) and 3rd party domains (mozilla.unbounce.com), when they are possibilities. In my experience, people really want .mozilla.org/com domains, because of the SEO advantage it confers.
I vaguely recall having a conversation that there could be risk using Unbounce's subdomain due to a potential long-term dependency on their service (they'd "own" the URL), whereas having a domain we own, we could re-direct to another service in the future. SEO is not a requirement here, as traffic is supposed to be tightly controlled through audience segmentation and targeted advertising. Also, Unbounce supports the use of multiple domains (you toggle when you setup an experiment), so I'm fine launching with anything that unblocks use of this service, and we could request/add more TLDs addresses later, as needed.
(In reply to planderos from comment #19) > I vaguely recall having a conversation that there could be risk using > Unbounce's subdomain due to a potential long-term dependency on their > service (they'd "own" the URL), whereas having a domain we own, we could > re-direct to another service in the future. So right, using something like mozilla-campaigns.org/com would strike the right balance here. On the one hand, it would be a name we own, but on the other hand, it wouldn't also have important other stuff under it. > SEO is not a requirement here, as traffic is supposed to be tightly > controlled through audience segmentation and targeted advertising. > > Also, Unbounce supports the use of multiple domains (you toggle when you > setup an experiment), so I'm fine launching with anything that unblocks use > of this service, and we could request/add more TLDs addresses later, as > needed. Minor general note: TLD == "top level domain" == org/com, not mozilla.org/com. I would prefer if we could go ahead and revert this CNAME, and go ahead with the mozilla-campaigns.org/com plan mentioned above.
Has anyone confirmed that unbounce supports "m-c.org/subdir" style custom domains?
(In reply to Richard Soderberg [:atoll] from comment #21) > Has anyone confirmed that unbounce supports "m-c.org/subdir" style custom > domains? Each team can setup the directory/path when they create their page. You can also move previously created pages to directories as well. Out of the box, all teams would have access to the root, so we'd have to just "train" them to create/use a directory.
In the past we've done security evaluations of third-party vendors so that we can comfortably assign Mozilla resources (and, in some cases, domains - blog.m.o and assets.m.o being two such examples) to them. Have any of our security groups evaluated Unbounce? If so, that might serve to address many of the concerns described above.
(In reply to Richard Soderberg [:atoll] from comment #23) > Have any of our security groups evaluated Unbounce? If so, that might serve > to address many of the concerns described above. To be blunt, I would rather we just isolate these things, rather than spend time evaluating them. Unless there's some compelling need to use *.mozilla.org/com, domain names are way cheaper than security staff time.
No argument here. I'll assume that we have not done a security evaluation for them.
We have done a RRA for unbounce. Though the reputation risks are medium we should no longer be in the habit of hosting 3rd parties.mozilla.* as we do not gain the ability to evaluate their codebase and do not control their security stance.
I agree with :rbarnes and :jeff that it would be great to get away from the default of hosting things under .mozilla.com/org simply for the SEO bounce that it gives us. As far as a security evaluation goes, I'm happy to take a look at them from a (web) security perspective once it is released. There's not much to test at the moment; I imagine that if they host random JavaScript and other code from us that a lot of the site security will come down to what we put there and not Unbounce's controls. We still have a reputational risk regardless of whether it's campaigns.mozilla.org or mozilla-campaigns.org; it's still our domain, our content, and our name. A defacement looks bad for us either way. But it certainly reduces our technical risk, and I agree with the above that domains are cheap. > planderos said: > I vaguely recall having a conversation that there could be risk using Unbounce's subdomain due to a potential long-term dependency on their service (they'd "own" the URL), whereas having a domain we own, we could re-direct to another service in the future. Domains are cheap and by using mozilla-campaigns.org, we can have full control over its use in the future. So it certainly gets my vote, if marketing is okay with it. Grab the domain, CNAME it to unbounce pages, and they should be able to get a cert all the same. Then we can remove campaigns.mozilla.com and all will be good. :)
To append to April's list of domain options, there's also "campaigns-mozilla.org", as IT has found that people mostly don't care if you swap out one of the . for a - instead.
Reopening to make clear that we need to change to "campaigns-mozilla.org", "mozilla-campaigns.org" or some such thing.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Removed the campaigns.mozilla.com CNAME. Claiming this to Webops, since domains are involved now. Holding for guidance on what precise domain name y'all would like us to purchase.
Assignee: infra → server-ops-webops
Component: Infrastructure: DNS → WebOps: SSL and Domain Names
QA Contact: cshields → smani
Summary: CNAME change request: campaigns.mozilla.com -> unbouncepages.com → Domain request for Campaigns (TBD)
Whiteboard: [kanban:https://webops.kanbanize.com/ctrl_board/2/3320]
(In reply to Richard Soderberg [:atoll] from comment #30) > Holding for guidance on what precise domain name y'all would like us to > purchase. mozilla-campaigns.org would be perfect. If not available, campaigns-mozilla.org would work, too.
(In reply to Richard Soderberg [:atoll] from comment #30) > Holding for guidance on what precise domain name y'all would like us to > purchase. Richard, are you guys going to take care of this purchase? Just confirming. Cheers.
(In reply to planderos from comment #32) > (In reply to Richard Soderberg [:atoll] from comment #30) > > > Holding for guidance on what precise domain name y'all would like us to > > purchase. > > Richard, are you guys going to take care of this purchase? Just confirming. > > Cheers. Richard, please let us know if your group is taking care of this purchase.
Flags: needinfo?(rsoderberg)
Assignee: server-ops-webops → smani
Hey Karen, Apologies for the delay. We have purchased mozilla-campaigns.org and it's ready for use. Please let us know where you need it pointed or if you'd like to manage DNS yourselves (by opening a new bug, in the same component) and we can work with you to figure out a path forward, accordingly. Thanks!
Status: REOPENED → RESOLVED
Closed: 9 years ago → 9 years ago
Flags: needinfo?(rsoderberg)
Resolution: --- → FIXED
MarkMonitor Order number : 6584275
You need to log in before you can comment on or make changes to this bug.