5 Applying TLS to the Web
5.1 Certificate Handling and Information
5.1.2 Augmented Assurance Certificates
Web user agents MUST establish that a trust anchor is [Definition: AA-qualified ] through some out of band mechanism consistent with the relevant underlying augmented assurance specification.
Opera establishes out of band in accordance to the CABForum's EV Guidelines
Implementations MUST NOT enable users to designate trust roots as AA-qualified as part of a different interaction. Implementations MAY make user interfaces available for the purpose of designating AA-qualified trust roots. Such user interfaces MUST be focused on this specific task. In particular, the notions of an AA-qualified trust root and an interactively accepted trust root are mutually exclusive.
Opera does not allow users to designate trust roots as AA-qualified
To derive a human-readable subject name from an AAC, user agents MUST use the Subject field's Organization (O) attribute.
Opera does use the Subject field's Organization (O) attribute
If the certificate's Subject field does not have an Organization attribute, then user agents MUST NOT consider the certificate as an augmented assurance certificate, even if it chains up to an AA-qualified trust root. User agents MAY consider such a certificate as an ordinary validated certificate.
Opera does not accept AA certs that do not have an Organization attribute
5.1.4 Logotype Certificates
Opera has no support for logotypes.
5.1.5 Self-signed Certificates and Untrusted Root Certificates
Web user agents MAY support [Definition: pinning] a self-signed certificate or more generally a certificate chain that leads to an untrusted root certificate to a particular Web site
Opera supports pinning
The interaction that enables users to pin a certificate to a destination SHOULD NOT cause a self-signed certificate to be pinned to more than one site, identified through URI scheme, domain, and port.
In Opera it is only possible to pin to one site
The interaction MUST NOT cause an untrusted root certificate to be accepted automatically for additional sites.
In Opera unrtusted root certificates are not accepted automatically for any sites beside the pinned one.
Opera does not support petnames
5.3 Mixed Content
A Web User Agent that can display an AA indicator MUST NOT display this indicator unless all elements of the page are loaded from servers presenting a validated certificate, over strongly TLS-protected interactions.
Opera not only complies to that, but has even a "strict mode" that allows to display as AA a site that serves all elements with strong TLS encryption and AA certificates.
5.4 Error conditions
5.4.1 TLS errors
If multiple error conditions apply, the most severe signalling level currently known MUST be used, as defined in 6.4 Error handling and signalling.
Opera signals the most severe error
When, for a TLS-protected HTTP connection, the certificate chain presented by the server does not lead to a trusted root certificate, and the certificate chain presented was not pinned to the destination at hand, the following applies to user agents that are capable of storing and using information about certificates that were previously encountered: 1. If a validated certificate (including an augmented assurance certificate) was previously presented by the same destination, then error signalling of class danger (6.4.4 Danger Messages) MUST be used. 2. If a different certificate was previously pinned to the same destination, then error signalling of class warning or above (6.4.3 Warning/Caution Messages , 6.4.4 Danger Messages) MUST be used. User agents MAY offer the possibility to pin the newly encountered certificate to the destination at hand. 3. Otherwise, user agents MAY use error signalling of class notification (6.4.2 Notifications and Status Indicators ) to offer pinning a given certificate, consistent with 5.1.5 Self-signed Certificates and Untrusted Root Certificates. 4. Otherwise, user agents SHOULD use error signalling of class warning or above (6.4.3 Warning/Caution Messages , 6.4.4 Danger Messages).
Opera does not check for previous type of certificate or changed pinning, and goes directly for case 4
In the same circumstances, the following applies to user agents that are not capable of using information about previously encountered certificates. 1. Error signalling of class warning or above (6.4.3 Warning/Caution Messages , 6.4.4 Danger Messages) MUST be used to signal the error condition. 2. User agents MAY offer a possibility to encounter newly encountered certificates to the destination at hand.
Opera displays a warning and offers a possibility to pin the certificate
User agents SHOULD store the state of certificates that were previously encountered. (specifically, whether or not a site previously presented a validated certificate). Historical TLS information stored for the purposes of evaluating security relevant changes of behavior MAY be expunged from the user agent on the same schedule as other browsing history information. Historical TLS information MUST NOT be expunged prior to other browsing history information. For purposes of this requirement, browsing history information includes visit logs, bookmarks, and information stored in a user agent cache.
At present Opera 9.5 does not store information about type of certificate used at a site
When certificate information is presented in these interactions, human-readable information derived from the certificates (e.g., Common Name or Organization attributes) in question MUST NOT be presented as trustworthy.
No indication about thrustworthiness is made. Dialogs mention "Holder" and "Issuer", together with information about the problem
When certificate information is presented in these interactions, web user agents MUST NOT display identity information derived from a self signed or untrusted certificate in a warning or error message. Web user agents MAY display this information in a dialog or other secondary chrome reachable through the warning or error message or dialog.
Information is presented in secondary chrome as Holder and issuer. First page of information only identifies the hostname, second panel holder and issuer, the third page the details of the certificate
When, for a TLS-protected HTTP connection, the certificate presented is found to have been revoked, error signalling of class danger (6.4.4 Danger Messages) MUST be used.
Opera refuse to connect, showing an error page.
When, for a TLS-protected HTTP connection, the certificate presented is found to have been expired, error signalling of class danger (6.4.4 Danger Messages) MUST be used. Note that user agents that apply Relaxed Path Validation to non-AA certificates will never detect this error condition for such certificates.
Opera displays a Warning. At present it may not be feasible to use Danger for this, however much we would want to do so
When the URL corresponding to the transaction at hand does not match the certificate presented, and a validated certificate is used, then error signalling of level danger(6.4.4 Danger Messages) MUST be used.
Opera displays a Warning. At present it may not be feasible to use Danger for this, however much we would want to do so
If TLS negotiation otherwise fails, error signalling of level danger (6.4.4 Danger Messages) MUST be used.
Opera do use a fatal error page for this
5.4.2 Error Conditions based on Third Party or Heuristic Information
User agents that use third party services or heuristic approaches to assess the possible danger of a pending Web transaction MUST use error signalling of class danger (6.4.4 Danger Messages) to signal positively identified dangers, e.g., identified malicious downloads or exploits of user agent vulnerabilities.
To signal risks that are identified with high likelihood, but involve further user decisions (e.g., phishing heuristics were triggered), error signalling of class warning or above (6.4.3 Warning/Caution Messages , 6.4.4 Danger Messages) MUST be used.
Opera uses 3rd party phishing and malware protection and signals class danger.
Opera lowers security status.
5.4.4 Insecure form submission Users interacting with a TLS-secured page are likely to develop the impression that information submitted during these interactions will be submitted through strongly TLS-protected. User agents SHOULD warn users, using an error of class Warning or above (6.4.3 Warning/Caution Messages , 6.4.4 Danger Messages), if form submissions from a TLS-secured page are directed to an unsecured channel.
6 Indicators and Interactions 6.1 Identity and Trust Anchor Signalling 6.1.1 Identity Signal Web user agents MUST make information about the identity of the Web site that a user interacts with available. This [Definition: identity signal ] SHOULD be part of primary user interface during usage modes which entail the presence of signalling to the user beyond only presenting page content. Otherwise, it MUST at least be available through secondary user interface.
The information is available through primary chrome on TLS secured pages, and at least through secondary chrome for all other pages.
If a positive form of identity is available, the identity signal MUST be part of primary user interface when any identity sources that are from unauthenticated or untrusted sources are (also) part of the primary user interface. These sources include URLs.
Opera's Identity information is part of the address bar in primary chrome, when the displayed document is 100% OK
User interactions to access this identity signal MUST be consistent across all Web interactions facilitated by the user agent, including interactions during which the Web user agent has no trustworthy information about the identity of the Web site that a user interacts with. In this case, user agents MUST indicate that no information is available.
The page info dialog is always accessible through the menu. However, on TLS secured pages it is also more easily accessible through the padlock.
User agents with a visual user interface that make the identity signal available in primary user interface SHOULD do so in a consistent visual position. Web Content MUST not obscure security chrome, 7.4.1 Obscuring or disabling Security User Interfaces.
The padlock is always in the same position and cannot be hidden or spoofed by web pages.
6.1.2 Identity Signal Content
Information displayed in the identity signal MUST be derived from validated certificates, or from user agent state. Web user agents MUST NOT use information as part of the identity signal that is taken from unauthenticated or untrusted sources.
The information displayed are always derived from the certificate name, or extensions in the certificate
During interactions with a TLS-secured Web page for which a petname has been defined, the identity signal MUST include that petname.
Opera does not support pet names.
During interactions with a TLS-secured Web page for which the top-level resource has been retrieved through a strongly TLS-protected interaction that involves an augmented assurance certificate, and for which all dependent resources have been retrieved through interactions that involve validated certificates, the following applies: * The identity signal MUST include human-readable information about the certificate subject, derived as specified in 5.1.2 Augmented Assurance Certificates, to inform the user about the owner of the Web page, unless a petname is displayed. * For Web user agents that use a visual user interface capable of displaying bitmap graphics the identity signal MAY include display of a suitable logotype, selected according to the rules in 5.1.4 Logotype Certificates. * Web user agents that use sound to communicate with the user MAY render an audio logotype that is embedded in the certificate using the logotype extension, according to the requirements in 5.1.4 Logotype Certificates.
Opera includes human-readable information. It does not suppoort audio or video logotypes.
During interactions with a TLS-secured Web page for which the top-level resource has been retrieved through a strongly TLS-protected interaction that involves an validated certificate (including an augmented assurance certificate), the following applies: * If the identity signal does not include any other human readable information about the identity of the certificate subject (derived, e.g., from an augmented assurance certificate or a petname), then it MUST include an applicable DNS name retrieved from the subject's Common Name attribute or from a subjectAltName extension. * The identity signal MUST include the Issuer field's Organization attribute to inform the user about the party responsible for that information. * Subject logotypes derived from certificates SHOULD NOT be rendered, unless the certificate used is an augmented assurance certificate.
Opera disaplys at least the server name, retrieved from subject's Common Name attribute. The Issuer field's Organization attribute is available at least in secondary chrome. Opera supports no logotypes.
During interactions with a mixed content Web page, the identity signal MUST NOT include any positive indicators exceeding those in use for unprotected HTTP transactions. In this situation, the identity signal MAY include indicators that point out any error conditions that occurred.
Opera informs the user in primary chrome that an error has occurred.
During interactions with mixed content, Web user agents MUST NOT render any logotypes derived from certificates.
Opera does not support logotypes.
6.2 Additional Security Context Information
Web user agents MUST provide additional security context information as described in this section through one or more user-accessible information sources. These information sources can be implemented in either primary or secondary user interface. Where security context information is provided in both primary and secondary chrome, the presentation and semantics of the presented information MUST be consistent.
Opera presents this information consistently through the page info dialog.
The information sources MUST make the following security context information available: 1) the Web page's domain name 2) Owner information, consistent with 6.1.2 Identity Signal Content 3) Verifier information, consistent with 6.1.2 Identity Signal Content 4) The reason why the identity information is trusted (or not). This includes whether or not a certificate was accepted interactively, whether a self-signed certificate was used, and whether the self-signed certificate was pinned to the site that the user interacts with, and whether trust relevant settings of the user agent were otherwise overridden through user action.
Opera presents this information in the page info dialog.
The information sources SHOULD make the following security context information available: 1) Whether a Web page is TLS-protected, whether the protection is weak or strong, and the reasons for the value of the protection. 2) When the Web page is TLS-protected and a validated certificate was used, whether or not a certificate status check has been performed. 3) If a certificate status check has been performed, what the result was. 4) Whether the user has visited the site in the past. 5) Whether the user has shown credentials to this site. 6) Whether the user has stored credentials for this site. 7) Whether the site content was encrypted in transmission. 8) Whether the site content was authenticated. 9) Logotypes embedded in certificates used, consistent with 6.1.1 Identity Signal and 5.1.4 Logotype Certificates
Opera provides details on the TLS encryption, informs the user when a certificate check fails (points 1 and 2). Not 3-9.
Additionally, the information sources MAY make the following security context information available: 1) When the user most recently visited the site in the past. 2) When the user first visited the site in the past. 3) How often the user visited the site in the past.
1 and 3 are avialble in the browsing history.
User agents that provide information about the presence or absence of Cookies [RFC2965] MUST NOT make any claims that suggest that the absence of cookies implies an absence of any user tracking, as there are numerous tracking and session management techniques that do not rely on Cookies.
Opera does not make that claim.
6.3 TLS indicator
Web user agents MUST make information about the state of TLS protection available. The [Definition: TLS indicator] SHOULD be part of primary user interface during usage modes which entail the presence of signalling to the user beyond only presenting page content. Otherwise, it MUST at least be available through secondary user interface. As in the case of 6.1.1 Identity Signal, there may be usage modes during which this requirement does not apply. Web content MUST not obscure security chrome, 7.4.1 Obscuring or disabling Security User Interfaces.
Opera makes the information available in primary chrome, and with more details in secondary chrome. Web content cannot obscure or spoof the information.
User interactions to access the TLS indicator MUST be consistent across all Web interactions. This includes when TLS has not been used to protect those interactions. In this case, web user agents SHOULD indicate the interaction was not TLS protected. User agents with a visual user interface that make the TLS indicator available in primary user interface SHOULD do so in a consistent visual position.
Both TLS interaction and information to the user are consistent in Opera.
The TLS indicator MUST present a distinct state that is used only for TLS-secured Web pages. The User Agent SHOULD inform users when they are viewing a page that, along with all dependent resources, was retrieved through at least weakly TLS protected transactions, including mixed content. The user agent MAY accomplish this by using a third state in the TLS indicator, or via another mechanism (such as a dialog, infobar, or other means).
Opera has a distinct state for TLS protected pages. A different UI is used for pages that present some TLS problems.
6.4 Error handling and signalling
6.4.1 Common Error Interaction Requirements Error signalling that occurs as part of primary chrome SHOULD be phrased in terms of threat to user's interests, not technical occurrence.
Opera tries to communicate that.
Primary chrome error messages MUST NOT be phrased solely in terms of art, e.g., jargon. They SHOULD NOT refer the user to enter the destination site that caused the error, e.g., to provide feedback or obtain assistance. For error messages that interrupt the user's flow of interaction, user agents SHOULD enable the user to easily return to the user agent state prior to initiation of the last user interaction that led to the error signal.
Opera does not phrase error messages solely in terms of art. It allows the user to return to the previous site, or to navigate to a safe site (homepage).
For advanced users, error interactions SHOULD have an option for advanced users to request a detailed description of the condition that caused the interaction to occur.
The page info dialog provides advanced information.
6.4.2 Notifications and Status Indicators
Notifications and status indicators are used when the browser cannot accurately determine a security risk based on the current security context information available. These indicators SHOULD also be used for situations in which the risk level may vary based on user preference.
The notifications and status indicators are presented after evaluation of the user preferences.
For visual user agents, notifications and status indicators MUST be displayed in the user agent's persistent primary chrome. These indicators MAY include user interaction (e.g., forcing the user to click a button to continue the primary task). They MUST include a succinct textual description of their meaning.
They are present in the primary chrome, but not always include a succint textual description of their meaning - that info is available in the secondary chrome.
6.4.3 Warning/Caution Messages
Warning / Caution messages MUST be used when the system has good reason to believe that the user may be at risk based on the current security context information, but a determination cannot positively be made. These warnings SHOULD be used if the likelihood of danger is present, but cannot be confirmed.
Opera's warning and caution messages are presented in primary chrome.
Warning / Caution messages MUST interrupt the user's current task, such that the user must acknowledge the message.
They interrupt the user's current task and force the user to interaction.
For user agents with a visual user interface, headings of these warnings MUST include words meaning "caution" or "warning". The headings of these warnings MUST be the locus of attention.
Warning / Caution messages MUST provide the user with distinct options how to proceed (i.e., these messages MUST NOT lead to a situation in which the only option presented to the user is to dismiss the warning and continue). The options presented on these warnings MUST be descriptive to the point that their meanings can be understood in the absence of any other information contained in the warning interaction. These warnings SHOULD include one recommended option, and a succinct text component denoting which option is recommended. In the absence of a recommended option, the warning MUST present the user with a method of finding out more information (e.g., a hyperlink, secondary window, etc) if the options cannot be understood.
They provide succint information.
6.4.4 Danger Messages
Danger Messages MUST be used when there is a positively identified danger to the user (i.e., not merely a risk).
Opera does so.
The interactions communicating these messages MUST be designed such that the user's task is interrupted.
These interactions MUST be presented in a way that makes it impossible for the user go to or interact with the destination web site that caused the danger situation to occur, without first explicitly interacting with the Danger Message.
Opera does so. The only "issue" here might be that when the danger situation is determined by a 3rd party, the loading of the page is not delayed until information retrieval is complete, for performance reasons (we don't want to delay the user's browsing). The situation might occur that the danger message is presented after page loading - it will then force user interaction.
6.5 Chrome Reconfiguration
If a Web User Agent permits the user to administratively reconfigure the primary user interface in such a way as to suppress any of the displays required by this specification, then it MUST provide a simple administrative mechanism, such as a single button in a configuration menu, to reset the display to be in conformance with this specification.
Opera does provide a means to return to the default configuration.
7 Robustness 7.1 Chrome and User Interface Practices
7.1.1 Use Shared Secrets to Establish a Trusted Path
Web user agents that proactively present security context information to the user (or a channel presumed to eventually lead to the user, such as accessibility aides) MAY accept some presentation information from the user, and associate that information with parts of the user interface that are intended or commonly used to communicate trust information to users.
Opera does allow skinning and reconfiguration of some parts of the UI.
7.1.2 Keep Security Chrome Visible
For visual user agents, browser chrome SHOULD always be present to signal security context information. This requirement does not apply when UI is explicitly dismissed by the user.
This clause should apply to the authors of the skins/toolbar setups, and as a reccomendation to how the user configures his/her UI.
This requirement is scoped to a specific interaction: When multiple Web pages might be displayed, security critical chrome MAY be not present for those with which the user is not currently interacting. However, chrome used to communicate security context information that relates to the currently interacted Web page MUST always remain on the screen.
Depends on user configuration. The default certainly does adhere.
7.2 Do not mix content and security indicators
User interfaces used to inform users about security critical events or to solicit comment MUST employ techniques that prevent immediate dismissal of the user interface, e.g., by using a temporarily disabled "OK" button on user interfaces that make such an interaction paradigm available. When users interact with security relevant notifications (6.4.3 Warning/Caution Messages and above), interactions caused by Web content MUST NOT be granted control of the user agent's interaction
7.4 APIs Exposed To Web Content
7.4.1 Obscuring or disabling Security User Interfaces
Web user agents MUST prevent web content from obscuring, hiding, or disabling security user interfaces.
Web content cannot do this in Opera.
Web user agents MUST restrict window sizing and moving operations consistent with 7.1.2 Keep Security Chrome Visible. This prevents attacks wherein browser chrome is obscured by moving it off the edges of the visible screen.
It is always visible or readily accessible (e.g. collapsed address bar)
Web user agents MUST NOT allow web content to open new windows with the browser's security UI hidden. Allowing this operation facilitates picture-in-picture attacks, where artificial chrome (usually indicating a positive security state) is supplied by the web content in place of the hidden UI.
The security UI is always accessible
Web user agents MUST prevent web content from overlaying chrome. User interactions that are perceived to deal with browser chrome must not be detectable for Web content
Chrome cannot be overlayed by web content.
7.4.2 Software Installation
Web user agents MUST NOT expose programming interfaces which permit installation of software, or execution of privileged code without a user intervention.
Opera does not provide these interfaces
Web user agents MUST inform the user and request consent when web content attempts to install software outside of the browser environment. The interaction used MUST follow the requirements in 6.4.3 Warning/Caution Messages . Web user agents SHOULD NOT provide features which can be used by web content to install software outside of the browser environment without the user's consent. Web user agents MAY provide mechanisms for users to pre-consent to a class of software installations. Web user agents SHOULD inform the user when web content is installing software outside of the browser environment that is covered by a pre-consent.
Opera informs the user when web content tries to install software, and installation requires user interaction. Opera does not provide a mechanism for installation of a software class.
Web user agents MAY inform the user when web content attempts to execute software outside of the agent environment, and MAY also request user consent, but SHOULD NOT do so unconditionally for all types of content or software. If the agent chooses to do this then it SHOULD do so for specific content types, software types, or security context based on risk.
Opera can be configured to associate certain MIME types with other applications.
7.4.3 Bookmarking APIs
Web user agents MUST NOT expose programmatic interfaces that allow bookmarking without explicit user consent. That consent MUST follow the requirements from 6.4.2 Notifications and Status Indicators . Web user agents MUST NOT expose programmatic interfaces that allow bookmarking an URL that does not match the URL of the page that the user currently interacts with.
It is not possible to programmatically add bookmarks.
7.4.4 Pop-up Window APIs
With visual user interfaces that use a windowed interaction paradigm, Web user agents SHOULD restrict the opening of pop-up windows from web content, particularly those not initiated by user action. Creating excessive numbers of new popup windows is a technique that can be used to condition users to rapidly dismissing dialogs. This can be employed in interaction flooding attacks.
Opera does have a pop-up blocker that can be configured to either block all popups, or to allow only requested ones.
Web user agents which offer this restriction SHOULD offer a way to extend permission to individual trusted sites. Failing to do so encourages users who desire the functionality on certain sites to disable the feature universally.
Opera allows a per-site configuration.