News Archives - Enom BlogEnom Blog |

News
Category

SSL Certificate Validity Periods Reduced to 1 Year

July 2, 2020

News, SSL

Like

Views: 1321
Back in February of this year, Apple announced that as of September 1, 2020, its Safari browser will no longer trust newly registered SSL certificates with validity periods of two years. Two-year certificates registered up until August 31, 2020, will be trusted, but those registered on or after September 1, 2020, will not. To prevent incompatibility with specific browsers, Enom will implement a one-year max on SSL certificates in our system, as of August 15, 2020. Below we provide a bit of background information behind this change and, most importantly, outline what it means for Enom resellers.

Why are SSL/TLS validity periods being reduced to 1 year?

In the lead up to this change, there’d been for years an ongoing discussion in the Certificate Authority/Browser community around validity periods. On the one hand, shorter validity periods improve security by reducing the window of exposure if a certificate is compromised, and ensuring certificate holders are regularly updating their information (company name, address, active domains, etc). On the other hand, shorter validity periods mean more work for certificate users.

Just a few years ago, the maximum validity period was reduced from three years to two. Back in August of 2019, ballot SC22, which proposed a further reduction to one year, failed to pass at the CA/Browser Forum (the industry’s self-governing body). Apple then made the independent decision to enforce this new maximum as part of their “ongoing efforts to improve web security” for Safari users. And when one of the major browsers imposes a change, the industry accommodates.

How will this change SSL/TLS registrations on Enom?

As of August 15 Enom will only offer one-year validity periods for all our SSL certificates. Here’s what this will look like:
1. As of August 15, the Enom Control Panel will only provide the option to register certificates for one year
2. As of August 15, all API requests to register (PurchaseService) or update an SSL must be submitted with a NumYears value of 1, or must omit the NumYears value entirely. Submitting a period value other than 1 will generate an error.
Engaging with your Customers

While this change may create a bit more work for website admins, it also creates a great opportunity for you to reach out to your customers and sync up about their SSL and security needs. Some may want to take advantage of the current two-year period and repurchase their certificates prior to August 15.
Read More
Tucows Approaches to COVID Related Domain Registration

April 9, 2020

Industry Insight, News

Like

Views: 11014

From an early point in the current global crisis, it was clear to Tucows (Enom’s parent company) that we were going to need to do something new and different in how we responded to COVID-19 related domain registrations. Many of these domains are registered for good, helpful purposes, such as community organization, dissemination of healthcare information, and recording people’s experiences through this pandemic. Others, however, purport to sell COVID-19 cures, vaccines, or tests, none of which are legitimately available on the market today and all of which pose a significant health risk to the general public.

This blog post is going to run through the what, why, and how of our response to problematic or abusive COVID-19 related domain names and provide suggestions as to how our resellers and other hosting and CMS companies can help.

Before we dive in, we want to emphasize that this global pandemic is an exceptional situation, requiring Tucows to explore approaches we would not consider in other circumstances.

In helping to develop the DNS Abuse Framework, Tucows spent substantial time considering how domain names may be used to cause a threat to human life, and this work has been immensely valuable within the context of the COVID-19 pandemic. It is also important to note that our response to each and every issue that we find is contextual and dependent on the specific circumstances. We expect to return to our regular procedures as the pandemic and corresponding risks subsides.

Our actions

There are three major components to our COVID-19 related activities: identification, assessment for harm, and stakeholder engagement.

Identification

Tucows uses a relatively simple keyword search on all domains registered since December 2019 to flag relevant domains for manual review. We are also matching domain names on our platform to a number of externally-sourced COVID-19 related blocklists. Every day, members of our Compliance teamwork through our list of COVID-19 related registrations.

Assessment for Harm

As we mentioned above, a considerable number of COVID-19 related domain registrations are doing good and important things. We’ve seen many official websites from communities, hospitals, and other organizations come online over the past few weeks. Often, it is faster and easier for these organizations to use the website builder products offered by our reseller partners than for these organizations to host and build a site on their own infrastructure.

As Tucows is primarily concerned with domain names that represent threats to human life, we are prioritizing looking for those that resolve to websites purporting to sell COVID-19 tests or cures. We are deeply worried about the possibility that someone could take a fake test and then, based on those results, continue to spread COVID-19 in their community, endangering many others. We have found very few of these sites so far, but when we do, we ask the registrant for documentation that proves their legitimacy and authorization to sell. This is very similar to our standard practice for addressing reports of harmful online pharmaceuticals.

At this time, we have yet to see a site offering an unambiguous (albeit fake) cure that presents a risk of imminent human harm. We have seen cure-adjacent sites, purporting, for example, the (dubious) benefits of high-doses of vitamin C and the practice of alternative medicine. We’ve flagged these for review, but have not removed them from the DNS at this time.

Other types of Harm

We have also seen a number of COVID-19 phishing, botnet, and malware abuse issues; fortunately, we already have clear and well-established practices for dealing with these. For reports of misinformation, disinformation, price gouging, or fraud, we are working with regulators and law enforcement wherever possible to address these websites as we do not have the appropriate tools or experience to assess these independently.

Engagement with Stakeholders

An important component to all of the above has been communicating consistently with a variety of different stakeholders. This has included a number of our reseller partners who have seen large numbers of COVID-19 registrations. It has also included conversations with different law enforcement agencies, governments, and regulators. Our goal in these conversations is both to be transparent in what we can and cannot do and to ensure that the work of assessing website content is handled by those who are appropriately trained and empowered to do so wherever possible.

Why Review?

At least one major registrar has effectively blocked incoming COVID-19 related domain registrations. Tucows has chosen not to do this for a number of reasons; the primary one is that the Internet is an immensely powerful tool, especially in times of crisis where coordination is essential. The amazing sharing of information, mashups of data, official sites and even art that we’ve seen in our review is a daily reminder that allowing for creation is important. We think it’s important that registrants are able to respond as they see fit to the crisis, without impediment or delay. This approach vastly increases our burden and puts us in the uncomfortable position of having to assess the level of harm represented by a COVID-related domain and the website to which it resolves. However, we feel these circumstances are exceptional and are determined to do our part.

Steps our resellers can take

Hosting companies, CMS providers, and ecommerce platforms are in a better position than domain registrars to address content-related issues. Tucows resellers who offer these services may have the ability to remove specific pages or items from online stores whereas registrars have only one very blunt tool: we can take down the domain. To this end, we are also encouraging our resellers to monitor their registrations and platforms for COVID-19 related content. Now is an excellent time to review your Terms of Service and consider how you might apply them in the current circumstances. If you’re a Tucows reseller and would like assistance identifying COVID-19 related registrations, please reach out via help@enom.com.

Report COVID-19 Related Abuse

If you would like to report a COVID-19 related domain registered with Tucows that appears to be problematic, please submit an abuse complaint here: https://tucowsdomains.com/report-abuse/

Lastly, like all complicated problems, COVID-19 requires a regular review of our processes and iterating where possible in a very short amount of time. We, like you, very much look forward to a return to normalcy.

Read More
Highlights from ICANN66 Montreal

November 25, 2019

GDPR, Industry Insight, News

Like

Views: 2491
Montreal in November is not as bad as it sounds; the weather is crisp and clear, the snow isn’t too deep yet, and it doesn’t get dark until a reasonable time in the evening. It’s still not my top choice for a travel destination at this time of year, but the ICANN conference definitely made it all worthwhile. For those who couldn’t make it out to Montreal, here are the highlights.

How best to handle DNS abuse

While changes necessitated by the GDPR were a hot topic at ICANN66, we were pleased to see a lot of discussion about DNS Abuse and how best to address it. Front and centre in these conversations was the “Framework to Address Abuse”, a document signed by Tucows and other major registrars and registries hoping to standardize our industry’s approach to DNS Abuse. In that Framework, Tucows and our co-signatories proposed a definition of DNS Abuse that we believe is correct and appropriately limited, while also describing a set of non-DNS Abuse categories on which we would, nonetheless, take action. The plenary session on DNS Abuse was the most well-attended session at any ICANN meeting so far.

It’s impossible to summarize such a broad topic and intense discussion (you can, however, watch the whole thing online!), but here are the key takeaways:
- DNS Abuse is a topic that the community is working to address
- There’s concern around who should respond to Abuse and how to do so in a proportional manner
- There are already tools in place that ICANN Compliance could use to help in this effort
We’re committed to working within our space to address Abuse, and we look forward to collaborating with other groups in the domain name industry as this work continues.

You guessed it… the GDPR

The impact of the GDPR and other data privacy regulations on the Domain Name System remained a primary focus for ICANN66. Both the Expedited Policy Development Process (EPDP) team (the group that works to determine what the permanent replacement to ICANN’s Temp Spec must include and address) and the Implementation Review Team (the group responsible for transforming the EPDP’s Phase 1 recommendations into Consensus Policy) made good use of the opportunity for face-to-face meetings.

Work from the EPDP team

The EPDP team is in Phase 2 of their work, developing a System for Standardized Access and Disclosure (SSAD) by which third-parties can obtain non-public gTLD registration data. It’s a large project, and the work is divided up into a series of “building blocks,” each examining different aspects of this system, such as accreditation (for third-parties in search of data), data retention requirements, and auditing.

We think this is a useful approach, but some core questions remain unanswered, including the fundamental one: who is the entity making the disclosure decision?

When a third-party requests access to registration data, will that be relayed to the relevant registrar or registry operator, or will the SSAD operator make that determination? Could a standalone SSAD operator have all the relevant information needed to appropriately decide if the request should be fulfilled or denied? Could a registrar or registry operator provide data to be disclosed via the SSAD while remaining compliant with data protection laws? As the building blocks get finalized these underlying open issues are brought to the forefront, and we’re getting closer to the point where the EPDP can’t continue its work without these answers.

To that end, ICANN has set up a “Strawberry Team,” a group of ICANN staff working in parallel to the EPDP team. Just before ICANN66, they sent a proposed model for registration data disclosure to the European Data Protection Board, asking for feedback.

There’s a general sense of frustration among EPDP members around the lack of communication about this; the team had asked ICANN to share any proposals or models with them before sending it out to groups like the Data Protection Board, and that didn’t happen here. There’s also concern that this work should be happening within the multistakeholder model rather than alongside it.

Ultimately, if the European Data Protection Board (EDPB) provides advice, that can only be a good thing. However, as we wrote following ICANN64 in Kobe, it’s important to remember that any statement by the EDPB that the model is acceptable could easily be retracted in the future; it’s not a guarantee of legality. Instead, decisions around how to update ICANN contracts and Consensus Policies should be made by the ICANN Community, who are able to take relevant local laws and regulations into account while considering the policies our industry needs.

Work from the Implementation Review Team

Alongside the EPDP’s Phase 2 work, the Implementation Review Team (IRT) is in the midst of transforming the EPDP’s Phase 1 Recommendations into a “gTLD Registration Data Policy.” Once complete, this gTLD Registration Data Policy will replace the Temp Spec and permanently modify ICANN’s Registrar Accreditation Agreement (as well as other ICANN policies) to bring them into compliance with the GDPR and other data protection laws.

This new policy will cover:
- data collection
- transfer of data from registrar to registry
- transfer of data to data escrow provider
- publication of registration data
- logging
- data retention requirements
This gTLD Registration Data Policy will also include a section on “Reasonable Requests for Lawful Disclosure of Non-Public Registration Data.” You may be wondering how this ties into the EPDP team’s Phase 2 work developing a System for Standardized Access and Disclosure (SSAD): would they not go hand in hand? The difference is that the IRT’s Policy will govern how requests for data are handled when made directly to individual registrars or registry operators, while the SSAD is intended to be a standalone unified system with a single point of contact and operator.

There is not yet an expected date for when the new gTLD Registration Data Policy will become effective, but we will keep you posted as things develop.

Tucows’ involvement in the ICANN Community

The Tucows team also presented on panels and attended sessions on a variety of other topics. We discussed expectations for RDAP, the successor to the Whois protocol, based on outcomes of the EPDP and IRT; we worked with the joint registrar and registry “TechOps” team on a set of topics, including best practices for transfer authorization codes.

ICANN meetings are a unique combination of exhausting and exhilarating. Participants from all around the world come together to work on specific topics, with hundreds of sessions to choose from, and the public forums are always fascinating. We continue to work hard to make sure that the concerns of our customers and their registrants are represented at this important venue.
Read More
Our Ongoing Commitment to Combatting DNS Abuse

October 18, 2019

Announcement, Featured, News

Like

Views: 2592

Abuse is a significant problem on the Internet today and, as a provider of Internet infrastructure services, we constantly consider what role we should play in combatting this issue. We actively investigate and respond to reports of abuse, but like other registrars and registries, we’ve been alone in developing our approach—until now.

Abuse has been a growing topic of conversation in our industry. Today, several major registrars and registries released a DNS Abuse Framework defining what types of abuse to the domain name system (DNS) we are the appropriate parties to take action on. It’s our hope that this commitment by DNS providers to address abuse on our platforms will help establish industry-wide standards that both protect free speech and ensure that the Internet remains free and open while keeping malicious online activity in check.

What is DNS Abuse? On the surface that should be easy to answer: it’s abusive use of the domain name system. But as you get into the details, there are often more questions than answers. Who decides what is abusive? Who should respond when it happens? As a domain name registrar, our obligations are spelled out in the Registrar Accreditation Agreement (RAA), but although we must “take reasonable and prompt steps to investigate and respond appropriately to any reports of abuse,” (RAA 3.18.1) the RAA doesn’t provide a specific definition either of abuse or of what steps are reasonable.

For some registries, Specification 11 of their respective Registry Agreements provides more assistance, referring to specific types of behavior as security threats: pharming, phishing, malware, and botnets. Until now, however, there has not been a consistent, common understanding of how to define abuse, meaning we haven’t been able to come to an agreement on who should respond when it happens.

This new DNS Abuse Framework proposes a shared definition of DNS abuse, relying on the Internet & Jurisdiction Policy Network’s definitions of the four behaviors listed in the Registry Agreement plus spam (but only when spam email is used as a delivery mechanism for another type of abuse, such as malware). This Framework also considers additional types of abuse that DNS providers should respond to—even if we are not required to do so under our respective contracts. Reaching a common agreement about what constitutes DNS abuse is a crucial component of any industry-wide efforts to mitigate that abuse.

We encourage all Enom resellers to read through the Framework and become familiar with these types of abuse. To help, here’s a summary.

Malware is software that is installed on a device, such as a computer or smartphone, without the owner’s consent and for malicious purposes (that’s where the “mal” comes from). This includes things like viruses or spyware.

Botnets are networks of malware-infected computers, controlled remotely.

Phishing is the term for a fraudulent or copycat email that tricks users into thinking it’s legitimate in order to obtain personal data or financial information such as credit card numbers.

Pharming is the use of DNS redirection to bring Internet users to a different website than the one they intended to visit, in order to obtain personal data or financial information or install malware.

Spam is unsolicited email; it is included in our definition of DNS abuse when it’s used as part of the delivery method for these other types of abuse, such as malware or phishing.

As one of the collaborators of and signatories to this Framework, the Tucows family of registrars is committed to taking action when our services are used for these malicious purposes. As a community of stakeholders all seeking to provide safe and reliable Internet services, we’ve come together to find the most effective and appropriate means to mitigate these significant concerns. Since rules vary from jurisdiction to jurisdiction and there is no single global standard, we hope that this Framework helps to provide one. Having a consistent, industry-wide approach will help make responding to abuse faster and more successful, and this Framework can help those who encounter abuse online to know where to best direct their concerns so they’ll be addressed promptly.

Read More
We’ve refreshed our Webmail

June 19, 2019

Announcement, Featured, News, Resellers, Uncategorized

Like

Views: 3797

As our Custom Email service grows, we’re working to continually improve the platform while maintaining high availability.

One essential component of our email solution is our Webmail, which is both used by Enom’s direct customers and included in the email service our reseller partners can package as part of their own lineup.

So, we’re excited to share that we’re launching a new Webmail! Starting today, users can preview the new Webmail to get familiar with the refreshed interface before its official launch on September 5, 2019.

What’s new?

The new Webmail will provide a better email experience. You’ll notice improved workflows and a clean, mobile-responsive interface that makes it easier to send emails, manage contacts, organize important events, and more.

It’s important to note that the transition to the new Webmail will NOT impact contacts lists, settings, or any other existing mailbox data. The various functionalities and features of Webmail will remain, but their look, location, and how users interact with them, will change.

What Custom Email users need to know

On your Webmail login screen, you’ll now find an option to “Use the Webmail Interface Preview.” Simply toggle this on and log in to use the new Webmail interface. If you have any trouble, check out our Webmail Cheat Sheet.

Over the next few months, we encourage you to get familiar with the refreshed interface. On Sept. 5, 2019, the new Webmail will become the default experience for all users—our old Webmail will be retired.

We’d love to hear your thoughts on the new Webmail, particularly during this “Preview” period. You’ll find a Feedback option in the sidebar menu of the new interface.

What resellers need to know

If you already sell Custom Email…

The new interface offers an intuitive user experience and will NOT impact your customers’ mailbox data or your own settings or integration. That being said, there are a couple of things we recommend you do to prepare for this change:

Update your support and marketing resources

We’ve created a number of resources to help you out. On our Webmail Landing Page, you’ll find everything from reusable communication templates to detailed end-user guides—repurpose these materials as you see fit.

Let your customers know about the new Webmail

They’ll now find a “Use the Webmail Interface Preview” toggle option on their Webmail login page. Our White-Label Messaging templates can help you with your communication efforts.

Make note of the launch timelines

Today: your users can preview the new Webmail to get familiar with the refreshed interface.

Sept. 5, 2019: the new Webmail will become the default experience for all users—our old Webmail will be retired.

Let us know what you think!

Between now and Sept. 5, our new Webmail’s official launch date, we’ll be collecting feedback to help us improve the interface. Share your thoughts

If you don’t currently sell Custom Email…

Now is a great time to add email your lineup! Custom Email has all the standard features your customers want, but it costs a lot less than other solutions on the market.

It offers you the potential to boost revenue and customer loyalty while avoiding the resource and infrastructure costs associated with hosting your own email service. We also make migration easy.

Want to learn more? Contact our sales team today.

Read More

Support

Report Abuse
Help Center
Contact Us

Resources

WHOIS Lookup
Maintenance Alerts
Developers

Products & Services

Domain Name Search
Premium Domains
Web Hosting
SSL Certificates
Website Builder
Basic Email
Bulk Tools

© 2020 Enom Blog |