How Amazon CloudFront Secures Content Delivery

Securing delivery over the public internet is an inexplicably important part of cloud security. Amazon CloudFront is a highly secure, managed service and can help architects and developers secure the delivery of their applications and content by providing useful, and security supporting features.

As more and more businesses move to cloud computing, public awareness of the significance of the cloud also keeps on increasing. Cloud computing harnesses the power of the public internet to deliver results to the end-users. Securing the delivery is amongst one of the most important parts of cloud security.

Amazon CloudFront is a fast content delivery network (CDN) service that securely delivers data, videos, applications, and APIs to customers across the globe with low latency and high transfer speeds. CloudFront can be integrated with Amazon Web Services (AWS). The physical points of presence (PoPs) are directly connected with AWS global infrastructure and the service works seamlessly with AWS services, including Amazon Simple Storage Service (Amazon S3), AWS Shield, Amazon CloudWatch, and Lambda@Edge. Because CloudFront is the component nearest to end-users or the viewers in many workloads, and by default, its endpoint is open to the public internet. CloudFront is one of the first points on which the security of customers' applications relies on.

AWS follows the shared responsibility security model, and because CloudFront is a fully managed service, AWS responsibility includes physical infrastructure, network, servers, and operating systems and software. Securing data remains solely the responsibility of the customers. In order to strengthen the security posture of their applications, marketers must understand the framework of security measures used in CloudFront and what kind of security features they can utilize.

This document highlights how AWS protects CloudFront infrastructure (security of the cloud) and how marketers can harden their applications’ security (security in the cloud) by leveraging the features of CloudFront.

AWS Provides Security of the Cloud for Amazon CloudFront

AWS global cloud infrastructure provisions a variety of basic computing resources and services including compute and storage. The AWS global infrastructure is designed and managed according to security best practices as well as by a wide array of security and compliance standards. AWS customers should build web architectures on some of the most secure computing infrastructures in the world.

CloudFront is protected by the AWS global infrastructure security processes. The controls implemented include physical and environmental security such as fire detection and suppression and logical AWS access controls such as account review and audit, network security (fault-tolerant design), and other important secure design principles and practices.

Security is built into every layer of AWS infrastructure and carries into each of the services that run in it. AWS services including CloudFront have been architected to work efficiently and securely with all AWS networks and platforms. Every service provides extensive security features that have been engineered to help marketers protect sensitive data and applications.

Compliance Validation for CloudFront

Third-party auditors assess the security and compliance of CloudFront as an integral part of multiple AWS compliance programs. Marketers can download the third-party audit reports using AWS Artifact, a central resource for compliance-related information that provides on-demand access to AWS security and compliance reports and even allows marketers to select online agreements. Reports available in AWS Artifact include our Service Organization Control (SOC) reports and Payment Card Industry (PCI) reports, among other certificates. Marketers using CloudFront determine their data sensitivity and compliance objectives and applicable laws and regulations. AWS provides the following resources to help marketers determine and approach their compliance requirements:

• Quick Start Guides for Security and Compliance

These deployment guides discuss architectural considerations and provide steps for deploying security - and compliance–focused baseline environments on AWS.

• Architecting for HIPAA Security and Compliance

This whitepaper describes how companies use AWS to create Health Insurance Probability and Accountability Act (HIPAA)-compliant applications. The AWS HIPAA compliance program includes CloudFront as a HIPAA-eligible service. For those who have executed Business Associate Addendum (BAA) with AWS, the end-users can use CloudFront to deliver content that contains protected health information (PHI).

• AWS Compliance Resources

This is a collection of workbooks and guides that might apply to your industry and location.

• AWS Config

This AWS Service enables marketers to evaluate the configuration settings of their AWS resources and assess how well the resource configurations comply with internal practices, industry guidelines, and regulations.

• AWS Security Hub

This AWS Service provides marketers with a comprehensive view of their security state within AWS. This helps marketers check your compliance with security industry standards and best practices.

Securing HTTPS Delivery

HTTPS is a compulsory requirement for anyone who wishes to deliver data security over the internet. CloudFront has security controls for handling the Transport Layer Security (TLS) certificates and private keys used in the TLS handshake. During the TLS handshake between viewer and CloudFront, the CloudFront edge server must provide the correct TLS certificate and use its private key to decrypt a shared secret to be sued in the TLS session. These TLS certificates are issued or uploaded in AWS Certificate Manager (ACM).

CloudFront encrypts the private certificate with a data encryption key provided by AWS Key Management Service (AWS KMS). After KMS encryption, CloudFront encrypts data again with its own internal encryption, and thereafter deploys the encrypted certificates to each CloudFront edge server. The encryption keys used for the transfer mechanism are rotated every 24 hours by CloudFront. Decrypted private keys are seldom privately stored on the edge servers of CloudFront. The server decrypts the key each time the private key is loaded into memory and CloudFront records the access request to the private key information for auditing.

CloudFront uses the s2n library for TLS communication, an open-source library that is comparably new and more lightweight than OpenSSL. OpenSSL was initially released in 1998 and is a software library that includes TLS implementation. Open SSL has been used by many web servers. OpenSSL has more than 500,000 lines of code that makes it challenging to do core audits or reviews. The s2n implementation has around 6,000 lines of code which are regularly reviewed and tested by the Automated Reasoning Group from Amazon.

Resilience and availability

Several forms of DDoS migration are included automatically with AWS services. All AWS customers benefit from the automatic protections of AWS Shield Standard at no additional charge. AWS Shield Standard defends against the most common, frequently occurring network and transport layer (Layer 3 and Layer 4) Distributed Denial-of-Service (DDoS) attacks that target your website or applications. In each AWS Region, DDoS attacks are detected by a system that automatically baselines traffic, identifies anomalies, and, as necessary, implements mitigations. Users can use AWS Shield Standard as a part of a DDoS-resilient architecture to protect the web as well as the non-web applications.

Using services like CloudFront which is part of the Amazon Global Edge Network, can further improve the DDoS resilience of your application when one serves web application traffic from edge locations distributed around the world. The scale of Amazon Global Edge Network spans hundreds of PoPs, across dozens of cities and countries, which adds new PoPs frequently. This scale offers resiliency and a global presence and provides protection against localized availability problems.

The benefits of using CloudFront include:

• AWS Shield DDoS mitigation systems that are directly integrated with AWS edge services, reducing the time-to-mitigate from minutes to sub-seconds.

• Stateless SYN flood mitigation techniques proxy and verify incoming connections before passing them to the protected service.

• Automated traffic engineering systems can disperse or isolate the impact of large volumetric DDoS attacks.

• Application layer defense, in combination with AWS Web Application Firewall (AWS WAF), does not require charging your current application architecture (for example, in an AWS Region or on-premises datacenter).

• CloudFront enables users to cache static content and serve it from AWS edge locations, which can help reduce the load on your origin server.

• CloudFront automatically closes connections from slow reading or slow writing attackers (for example, a Slowloris attack).

• Protection from HTTP desync attacks, by integration with HTTP Desync Guardian.

• There is no charge for inbound data transfer on AWS. CloudFront Ensures Security in the Cloud Marketers can harden the security posture of their applications by using various features that CloudFront provides.

CloudFront Ensures Security in the Cloud

Marketers can harden the security posture of their applications by using various features that CloudFront provides.

1. Using HTTPS With CloudFront

   
   

When Hypertext Transfer Protocol (HTTP) is used to deliver data, it exposes your data to the public internet because the protocol transfers data in a clear text format. This can be exploited with man-in-the-middle attacks, which attempt to steal or tamper with private data. Hypertext Transfer Protocol Secure (HTTPS) is an extension of HTTP that provides secure and reliable communication over the internet. HTTPS uses TLS, which encrypts the transmitted data and checks the message integrity. TLS also provides a TLS certificate that authenticates the identity of a server. Some security standards, including Payment Card Industry Data Security Standard (PCI DSS) or industry-standard Apple iOS App Transport Security (ATS), require the use of HTTPS. The other benefits of using HTTPS include better search engine optimization.

CloudFront comes with native HTTPS support and can be configured to deliver pieces of content via HTTPS from viewer to origin, end to end.

2. Viewer HTTPS Configuration

   
   

CloudFront provides configurable HTTPS settings for two different connections:

• Viewer to CloudFront
• CloudFront to origin

In this context of HTTPS from viewer to CloudFront, CloudFront is a server that receives the TLS-initiating "Client Hello" in the TLS handshake process. Because the HTTPS is initiated by the client, CloudFront has options to:

• Accept both HTTP and HTTPS

• Let the client use HTTPS if they initiate the request via HTTP, or

• Ignore HTTP and respond with an error message

  
  

These options can be applied to a specific URI path so that the users can configure some part of their website to accept HTTP. This opens up a possible vulnerability or causes a bad user experience such as mixed content warning.

Marketers also need to set up a TLS certificate for their CloudFront distribution, when one serves the application with his own domain name (other than the default, *.cloudfront.net). In this case, the end-users can leverage AWS Certificate Manager (ACM), in which one can request the issuance of a domain validation certificate, or import an existing certificate with no additional cost. ACM supports certificate renewal for Amazon-issued certificates as well.

Another important configuration is choosing the TLS security policy. CloudFront provides a wide array of security policies each of which defines available TLS versions and cipher suites for viewer HTTPS. The oldest security policy still includes SSLv3 to support legacy clients; however, we recommend using the latest security policy. By leveraging this method, the viewer HTTPS connection will not only use the old cipher but will also get the benefit of the latest cipher, for example, the perfect forward secrecy (PFS).

Finally, the users can set up Server Name Indication (SNI) to be on or off. SNI is a TLS extension, which enables the client to put the server name in the initial TLS handshake “Client Hello” step. As CloudFront serves multiple domains, this extension helps CloudFront to choose the correct TLS certificate to provide to the client. SNI is supported by most modern browsers, but if one needs to enable using a legacy client that doesn't support SNI, one can choose to turn SNI support off which incurs extra cost. According to caniuse.com, more than 99% of clients use SNI-enabled agents.

CloudFront also supports Online Certificate Status Protocol (OCSP) stapling without further configuration, which enables the performance of HTTPS delivery by providing a certificate validation response together with a TLS certificate during the TLS handshake.

For Viewer-side HTTPS, TLS 1.3 is automatically supported when the client initiates a TLS 1.3 handshake. TLS 1.3 eliminates weak cipher suites, provides perfect forward secrecy, and supports 1-RTT TLS handshakes. Perfect forward secrecy means that each session will not be compromised, even if the private key used in session key exchange is compromised in the future. Because previous sessions are protected, attackers have limited access to private data. TLS 1.3 mandates this by using only ephemeral key exchange algorithms such as Elliptic Curve Diffie-Hellman (ECDHE).

TLS 1.3 reduces TLS handshakes to one round tip compared to two round tips in the previous TLS 1.2. This improves the TLS handshake latency up to 33% using the AWS internal test.

RTT TLS Handshake (TLS 1.2) and 1-RTT TLS handshake (TLS 1.3)

Origin HTTPS Configuration

When connecting to the origin with HTTPS, CloudFront becomes a client who initiates a TLS handshake. CloudFront operation is focused on authenticating the origin to avoid possible man-in-the-middle attacks. CloudFront trusts only the origin server when the TLS certificate provided by the origin server meets the following conditions:

·       The certificate matches the requested domain name

·       The certificate is issued by a trusted certificate authority (CA)

·       The certificate chain is correct

·       The certificate is not expired

If any of these conditions are not met, CloudFront drops the connection to the origin and responds with an error message to the client.

CloudFront validates either the Common Name (CN) or Subject Alternative Name (SAN) of the origin TLS certificate with the origin domain name that is registered in the CloudFront Distribution Settings by default. For example, if a CloudFront Distribution is set up to deliver https://www.example.com/ to viewers and forward requests to origin.example.com, the origin TLS certificate must contain origin.example.com in its CN or SAN, either the exact name or in wildcard form, such as *.example.com.

CloudFront uses the Host header value instead if you configure it to forward the Host header, which means that the origin’s TLS certificate must contain www.example.com/ in its CN or SAN. CloudFront also uses those domain names such as an SNI in its initial TLS handshake. You may want to utilize this fact when using an Application Load Balancer (ALB) as an origin because you must install a TLS certificate and its CN or SAN will not validate the default ALB domain (for example, alb-1234.us-east-1.elb.amazonaws.com) but will validate your own domain (www.example.com) instead. Alternatively, you can set a DNS record, such as origin.example.com, set the origin TLS certificate to validate that domain name, and associate the DNS record to the ALB via Amazon Route53 or another domain name server.

CloudFront varies whether the origin TLS certificate was issued by a trusted certificate authority (CA) by comparing the issuer with the Mozilla included CA Certificate List. Certificates that are issued by other CAs such as private certificates will not be validated and the connection will subsequently fail.

CloudFront enables you to specify the minimum TLS protocol version to connect to the origin. Using the latest version of TLS on both CloudFront Distribution and origin settings will avoid known attacks, such as POODLE or BEAST, which exploit older versions of TLS.

Securing Your Contents with CloudFront

CloudFront provides a number of methods to help protect content from unwanted access. One can specify geographical restrictions, have CloudFront authorize access to cloud-based on a signature (in the query string or in a cookie), and have CloudFront encrypt sensitive data fields so that only systems with the proper rights can access them.

Geo-Based Content Access

When one delivers content that should have restrictions based on the viewer's location, one can use CloudFront’s Geo-Restrictions feature to implement this request. For example, (vod) usually has a contractual condition that dictates only certain countries can play it. When Geo-Restrictions are enabled and configured to allow or deny the delivery to certain countries, CloudFront validates the viewer’s country information with this setting. When a viewer in a denied country tries to access the content, CloudFront responds with an error message.

Authorize Access At the Edge with Signed URL and Cookies

Yet another way to protect your content is to use signed URLs or signed cookies provided by CloudFront. When privileged or confidential content such as paid streaming or confidential reports needs to be delivered to authenticated viewers, one can leverage the signed URLs of CloudFront. Signed URLs validate parameters in the query string or cookies and allow access only when they are correctly signed with the private key of a pre-requisite key pair. You can build an application that authenticates users and share the signed URL or cookies to minimize origin authenticates efforts, cache the content in CloudFront, and protect against unauthenticated viewer access. Because signed URLs are based on a key pair system, the content will not be compromised even if the key is exposed. This ensures a better security posture as compared to shared, key-based token authorization.

The end users can use signed URLs by creating or uploading a key pair into their account security credentials. When a group of URLs, defined by a path pattern is set to use signed URLs or cookies, CloudFront searches the required parameters and validates their values on the request of those URLs. These parameters can be in the query string or cookie, where the former takes precedence if both are present. The fields in signed URLs or cookies vary slightly, based on which policy the end-users are employing. The policy defines conditions that must be matched to access the contents.

There are two types of policies that an end-user can use: a canned policy or a custom policy.

·       A canned policy is the simpler of the two policies and allows access if the request is made before the expiration time defined in the policy.

·       A custom policy has conditions such as start date-time, end date time, and IP address range in Classless Inter-domain Routing (CIDR) form.

When the condition is decided, signed URLs can be generated by signing the policy statement with the private key. The Amazon CloudFront Developer Guide provides the end-users with a lot of examples to refer back to.

Using CloudFront to encrypt sensitive data at the edge

If there exist multiple applications or services behind the origin endpoint, marketers may want to protect sensitive data the viewer submits via HTTP POST to the origin application stack. By using end-to-end HTTPS with CloudFront, users can ensure that sensitive data is encrypted from the client to the origin. Users can also add additional layers of security by encrypting fields in the POST form with a public key at the edge and allowing only certain applications to decrypt it. Say, if an eCommerce system receives recipient information, the phone number and address can be separately encrypted and is available only to the delivery application in decrypted form. The Field-Level Encryption (FLE) of CloudFront can be used in such a scenario.

To use the FLE of CloudFront, one must first upload the public key of a key pair. With this public key, users can make an FLE profile that defines the fields to be encrypted. Next, marketers can create a configuration that defines which content type (decided by an HTML form element’s enctype attribute) is associated with an FLE profile. When these fields are encrypted from CloudFront and forwarded to the origin, the relevant application can decrypt them using a private key.

Protecting Your Origin by Allowing Access to CloudFront Only

Controlling access to the origin is essential, along with controlling viewer access to have secure delivery via CloudFront. In this context, the origin should allow requests from CloudFront only and shut down the attempts from others.

S3 origin with CloudFront

S3 facilitates access control along with AWS Identity and Access Management (IAM), bucket policy, bucket ACL, and object ACL. When using S3 origin with CloudFront, users can use CloudFront Origin Access Identity (OAI) to secure S3 bucket access. OAI creates a principal that S3 can authenticate with, and it is used in a CloudFront distribution. By allowing this OAI principal an S3:GetObject action in bucket policy, S3 allows CloudFront distribution to access the content.

With this bucket policy set, marketers can turn on “Block all public access” to make the S3 bucket reachable only through CloudFront.

Custom Origin with CloudFront

Unlike S3, which is a static object storage system, custom origins such as web servers can inspect incoming HTTP requests and decide to discard the request. Users can allow only the trusted CloudFront distribution to access their origin by adding a custom header with a secret value to the original request in CloudFront, and setting up header inspection from the origin side. ALB has a rule that can be used for this header inspection purpose if an origin web server is on AWS.

CloudFront publishes its IP address ranges along with other Amazon services, without any prior setting or cost requirements to start with. This enables users to allow CloudFront IP address ranges in their origin firewall or add them into security groups. Users might require more than one security group to allow all CloudFront IP ranges.

By using an IP allowed list and header inspection together, custom origin allows only chosen CloudFront distribution to access its private content.

Improving Security by Enabling Security Specific Headers

To improve the security of their content, the users can use HTTP security headers that are natively supported by the HTTP protocol and most modern browsers. These security headers tell the browser how to behave when handling website content. They enable features such as enforced communications over HTTPS or defining from where JavaScript content can be loaded.

According to the Open Web Application Security Project (OWASP), there are ten headers related to security that should be considered as part of web application security:

·       HTTP Strict Transport Security (HSTS)

·       Public Key Pinning Extension for HTTP (HPKP)

·       X-Frame-Options

·       X-XSS-Protection

·       X-Content-Type-Options

·       Content-Security-Policy

·       X-Permitted-Cross-Domain-Policies

·       Referrer-Policy

·       Expect-CT

·       Feature-Policy

Security headers are commonly implemented using the web application configuration, but when that is not possible, they can be added as part of the request-handling process in CloudFront by modifying the origin response using a Lambda@edge function. An example implementation can be cited in this blog post. This solution adds the headers to the origin response, keeps that cached in CloudFront, and updates it every time content is refreshed.

Another consideration for enhanced security using HTTP headers is the appropriate configuration of Cross-origin sharing (CORS). In modern applications, the use of cross-domain resources is a necessity. The default restriction from browsers that only allows content from the same origin is impractical. To allow requests that have different origins (domain, protocol, and port), CORS must be enabled.

A number of HTTP headers relate to CORS but two response headers are most important for security:

·       Access-Control-Allow-Origin specifies which domains can access a site.

·       Access-Control-Allow-Methods specifies which HTTP request methods (GET, PUT, DELETE, and others) can be used to access resources.

To implement CORS securely, marketers must associate a validation list with the Access-Control-Allow-Origin header that identifies the specific domains that can access resources. Then your application can validate against this list when a domain requests access.

Protecting from external threats at the edge

When your application runs on AWS, you can leverage both CloudFront and AWS WAF to defend against application-layer DDoS attacks.

By using AWS WAF, users can configure web access control lists (Web ACLs) on their CloudFront distributions to filter and block requests based on request signatures. Each Web ACL consists of rules that users can configure to string match or Regular Expression (regex) match one or more request attributes such as the URI, query-string, HTTP method, or header key.

By using the rate-based rules of AWS WAF, users can automatically block the IP addresses of bad actors when requests matching a rule exceed a threshold that the users define. Requests from offending client IP addresses will receive a "403 Forbidden" error response and will remain blocked until request rates drop below the threshold. This is useful for mitigating HTTP flood attacks that are disguised as regular web traffic.

To block attacks from known bad-acting IP addresses, users can create rules using IP match conditions. Users can also use AWS-managed WAF rules, or use Managed Rules for AWS WAF offered by sellers in the AWS Marketplace. These rule sets can block specific malicious IP addresses that are included in IP reputation lists. Both AWS WAF and CloudFront enable users to set geo-restrictions to block or allow requests from selected countries. This can help block attacks originating from geographic locations where one doesn’t expect to serve users.

Those subscribed to AWS Shield Advanced can engage with the AWS DDoS Response Team (DRT) to create rules to mitigate an attack that’s hurting the availability of their application.

AWS Firewall Manager can be used to centrally configure and manage AWS WAF rules for CloudFront distributions across organizations. The AWS Organizations management account can designate an administrator account, which is authorized to create Firewall Manager policies. These policies allow users to define criteria, such as resource type and tags which determine where rules are applied. This can be beneficial for those who have multiple accounts and want to standardize their protection. Firewall Manager also allows users to create policies that manage AWS Shield-protected resources and VPC security groups.

How to Manage the Access Permissions to CloudFront Resources

To operationalize the CloudFront resources such as creating a distribution or invalidating an object, one can use AWS IAM. IAM allows users to securely control access to AWS resources by enabling them to control who is authenticated (signed in) and authorized (has permissions) to use resources. One can create and manage AWS users, groups, roles, and permissions to allow or deny actions within AWS services.

IAM offers AWS-managed policies created and administrated by AWS that are designed to provide permissions for many common use cases. For example, CloudFrontFullAccess provides full access to the CloudFront console plus the ability to list S3 buckets. CloudFrontReadOnlyAccess provides access to CloudFront distribution configuration information and list distributions. In some scenarios, one might grant a specific level of access to a resource that one specifies. For example, one might allow the update, delete, and create invalidations access to a distribution that one specifies by the distribution's Amazon Resource Name (ARN). One can create his own customer-managed policies that one administers in his own AWS account.

One can attach these policies to multiple principal entities to give each entity the permissions that are defined in the policy. These are referred to as Identity-Based policies. The policies can also be attached to resources, referred to as resource-based policies. Even though CloudFront doesn’t support resource-based policies, it does support resource-level policies that enable you to use ARNs to specify individual resources in a policy.

One can define more granular permissions with tag-based policies by granting access to specific resources, based on an authorization strategy that defines permissions based on attributes. In AWS, these attributes are called tags. One can define which users can perform actions on a distribution, based on the tag that it already has. For example, tagging resources and using tags in policy statement conditions can help you grant access to specific resources, as the number grows over time, without having to continuously add them to the policy.

For a list of actions that one can specify to grant or deny permissions to use each action, see Actions, resources, and condition keys for Amazon CloudFront in the IAM user guide.

Logging and Monitoring in CloudFront

Logging and monitoring are important for maintaining the availability and performance of CloudFront. There are several tools available in the AWS repository for monitoring the CloudFront resources and activity logs to respond to potential incidents.

The first service to consider is Amazon CLoudWatch as it provides marketers with data and actionable insights from your resources. CloudFront is integrated with Cloudwatch, and automatically publishes six operational metrics per distribution. One can monitor these metrics to detect anomalous behavior and create alarms. One can create a single metric over a time period that one specifies. If a metric exceeds a given threshold, a notification is sent to an Amazon SNS topic or an AWS Auto Scaling policy.

For example, receiving a notification when the 4xx error rate exceeds 1% (which helps you identify clients receiving 403 Forbidden errors) assists you to quickly identify the start of a possible DDoS attack. So does receive a notification that the total amount of requests exceeds the expected value specified in units.

There are additional metrics that can enable a cost. These units must be enabled for each individual distribution that requires it. For example, one can monitor and combine error rate and cache hit rate to measure CloudFront efficiency and alert on events as they occur, monitor a drop in the CHR, or monitor an increase in 5xx errors.

One can also opt to enable CloudFront access logs, which provide detailed records about requests that are made to a distribution. This access log information can be useful in security and access audits. One can enable standard logs at no additional cost that are delivered to the S3 buckets of your choice. Another option is real-time logs that, for a fee, are delivered within seconds of receiving the requests to the data stream of your choice in Amazon Kinesis Data Streams.

Querying these logs enables one to explore users’ surfing patterns across your web properties that are served by CloudFront. For example, one can query for detailed HTTP status code responses on a certain day or hour or statistics based on the URL paths.

It’s a good practice to review CloudFront service activity with AWS CloudTrail, which provides a record of actions taken by a user, role, or AWS service in CloudFront by automatically recording and storing event logs. Using the information collected by CloudTrail, one can determine who made the request, when it was made, and other additional details.

CloudTrail helps one track and automatically respond to activity threatening the security of your AWS resources with Amazon CloudWatch Events integration. One can monitor specific CloudFront API requests by creating a CloudWatch Event rule. A rule matches incoming events and routes them to targets for processing. For example, one can create a rule to trigger an SNS topic when the API UpdateDistribution is requested.