Hello Wilco,

Thanks for reporting this to Red Hat.
We assigned CVE-2015-0210 to this issue.
This report will assessed by Red Hat Product Security team, you might watch the flaw bug for the progress: https://bugzilla.redhat.com/show_bug.cgi?id=1178921 .

Please let us know when did you plan to make this issue public, and if you contacted other vendors/distributions about this already?

(In reply to Vasyl Kaigorodov from comment #2)
> Please let us know when did you plan to make this issue public, and if you
> contacted other vendors/distributions about this already?

This issue should be considered public, see e.g.:

https://bugzilla.gnome.org/show_bug.cgi?id=341323#c19

However, it does not seem wpa_supplicant upstream bugzilla instance is still accessible to see what was included in the upstream report and what the upstream response was.

Well, the issue is mostly known by attackers already and exploited in the wild.. it needs to be fixed soon though.

I do plan on presenting this issue to a wider audience in April/May.

A couple of things need to be fixed:
1. subject_match needs to be replaced with either an exact CN match or an exact subject match, matching on a substring of a host name is not very useful.
2. 

-- Wilco

Cont'd:

2. the GNOME interface needs to expose this field, because right now the user can only choose a secure set up by going into configuration files and setting subject_match (assuming 1 is fixed)

3. It would be best if at first connect, the CA + CN of the certificate are pinned if the CA is in the trust store and the user does not configure anything. This way the user has a secure configuration without even knowing the details.


... But I'd settle for 1 and 2 fixed, because this is exploited in the wild on eduroam, spacenet and any WPA2 enterprise setup that has RHEL connecting to it is vulnerable.

-- Wilco

In any case 1 should be fixed in the short term so people doing 'the right thing' are at least protected.

Wouldn't a CVE-2013-XXXX need to be assigned rather than a CVE-2015-XXXX?

Are you already in contact with upstream? It seems their bug reporting venue is a public mailing list, so perhaps contact the author directly. Although the issue was indeed already publically reported in 2013, it may be fair to give him a heads-up before we publicize it explicitly.

(In reply to Thijs Kinkhorst from comment #6)
> Are you already in contact with upstream? It seems their bug reporting venue
> is a public mailing list, so perhaps contact the author directly. Although
> the issue was indeed already publically reported in 2013, it may be fair to
> give him a heads-up before we publicize it explicitly.

And so we can fix it in the same way that upstream does (full subject match, full CN match, suffix match rather than substring match, etc).

I will contact Jouni Malinen and cc this bug.

I added Jouni to the cc of this bug and sent him this:

--- 

Hi Jouni,

Debian and Red Hat have assigned CVE-2015-0210 to wpa_supplicant for a broken subject_match check. I have added you to the bug cc list, so that you can view it.

This is the content of the bug report:

wpa_supplicant, linked against openssl performs this check:

    if (depth == 0 && match && os_strstr(buf, match) == NULL) {
        wpa_printf(MSG_WARNING, "TLS: Subject '%s' did not "
               "match with '%s'", buf, match);
        preverify_ok = 0;
        openssl_tls_fail_event(conn, err_cert, err, depth, buf,
                       "Subject mismatch",
                       TLS_FAIL_SUBJECT_MISMATCH);
    }

strstr() is vulnerable to extension attack, for instance, one would like to
match on /CN=wireless.nikhef.nl, but explicitly not match on
wireless.nikhef.nl.honestachmed.tr. There is no way to implement a secure
EAP-TTLS/PEAP configuration using public certificates this way.

When linked against GnuTLS, the problem is even worse:

      if (i == 0) {
            /* TODO: validate subject_match and altsubject_match */
        }

Now, it is current best practice to run EAP-TTLS/PEAP with public certificates,
because on Windows, this automatically pins the CN and CA from the certificate.

On OS X and IOS, the certificate is always pinned, but can't be replaced without
generating warnings for the user.

With wpa_supplicant, any such configuration is insecure. With SSL, always check
the subject of the certificate, expiry date and signature.


I advise the following actions:
1. Change subject_match to an exact CN match (full hostname on the certificate)
2. Automatically PIN the CA and CN if the CA is in the trust store, so that users have a safe default if a trusted CA is used. For self-signed certificates, pin the fingerprint.
For CA-signed certificates, do not PIN the fingerprint, so not to bother the user with a security message if the certificate gets replaced by a fresh valid one.
3. Add an API for interaction with Network Manager for the user interaction of trust messages.


-- Wilco

It looks like subject_match is being used for something it was never designed for. It is documented to be a "substring match aganst the subject" in the format that OpenSSL X509_NAME_oneline() returns (/C=US/ST=CA/L=San Francisco/CN=Test AS/emailAddress=as) which itself is a legacy, human readable format that is not really useful for the purpose that case seems to be describing.

If you want to do a suffix match on a domain, domain_suffix_match should be used instead if the certificates includes dNSName elemetn in the SubjectAltName. If you really want to do such matching against the CN (which CN? there can be multiple) in the subject name, that would require new functionality to be added.

However, the use case you seem to describe here does not sound like something that should be using any kind of (alt)subject name matching in the first place. If you want to require a specific server certificate to be used, you should use ca_cert="hash://server/sha256/<cert hash>" configuration.

Regarding use of GnuTLS: subject_match is against that legacy OpenSSL human readable format and it does not make much sense to extend that for anything new. tls_gnutls.c could be modified to reject any configuration with such match strings included to make it less likely to result in unexpected behavior.

I would also point out that there is a reason for making OpenSSL the default option for wpa_supplicant builds. GnuTLS interface has received significantly less testing and may lack significant functionality. If any distro is using that with wpa_supplicant, I would recommend them to consider moving to OpenSSL or being prepared to go through significant testing effort. There has been very limited interest in the GnuTLS interface over the years from the upstream wpa_supplicant project view point and as such, not much justification for using effort to work on it.

Hi Jouni,

Matching against a hostname and subjectAltNames would work, though this should still be pinned.

Certificate pinning on the fingerprint is a huge burden when replacing certificates (Imagine replacing configuration files for all your users on the same day, without network connectivity), what should be used is a subjectAltName/CN + CA.

This is what many people are currently using subject_match for, but an exact match to a hostname/CN would be better. I recommend dropping support for subject_match, since it gives the feeling of security, while in fact it adds very little. 

Pinning should mostly always be done on CN + CA, so that the certificate can be replaced when it expires. Certificate hash pinning should only be done for self-signed certificates.

-- Wilco

Note that in Fedora/RHEL we link wpa_supplicant against OpenSSL only.

I'm not sure I've understood what exactly you mean with "pinning" in this context if that is different from specifying a specific server certificate. It sounds like you do not want to select a single certificate (i.e., want to allow the server certificate to be renewed). Could you describe what certificate field(s) you think should be matched against? Please note that a certificate may have zero, one, or multiple CNs in the subject name. If you are saying "CN", that is unclear since the exact rules would need to be specified for the case of no CN (that sounds clear, reject) and multiple CNs (is it enough for any of them to match?).

In general, I'd recommend using domain_suffix_match (i.e., matching against SubjectAltName dNSName element(s)). If there is a reason to do something else, those exact rules for desired matching needs to be clearly specified first.

Another way of pinning a certificate could use issues + serial number (assuming same serial number is used when renewing, but that is likely not guaranteed).

I agree that subject_match should not be further extended taken into account its unreliability for tasks it can potentially be used. I'm not sure I would remove it, though, since that could break existing configurations and prevent wpa_supplicant from even starting. In other words, the configuration field itself will need to be parsed. Whether a network with that field with a non-empty value should be disabled is another question and I'm not sure I would go even that far. Anyway, any new rule will use a different field and what to do with existing subject_match, altsubject_math, subject_match2, and altsubject_match2 is a completely independent item.

With pinning in this context I mean that wpa_supplicant should remember these settings at first connect to provide a usable default.

But if domain_suffix_match should be used in this case, almost everybody is using wpa_supplicant incorrectly (See for instance the Android Java wpa_supplicant bindings: https://developer.android.com/reference/android/net/wifi/WifiEnterpriseConfig.html). 

Typically, with any TLS session one should verify: 
1. Does the certificate belong to the person I want to connect to (Usually CN + SubjectAltName dNSNames)
2. Is the certificate still valid?
3. Does it have a valid trusted signature (CA-signed)

For RADIUS it is not much different, except the dNSName can't be automatically verified, so this should be explicitly configured or pinned to the profile.


Breaking existing configurations if they are insecure would be acceptable (in my view). It may break, but it should break loudly and tell the user what to do.

-- Wilco

I'm not sure I'd agree with wpa_supplicant being the component deciding when and how to remember some criteria from a server certificate used for the first connection for a network porfile. Especially for cases when used with NetworkManager, the network profile is stored externally anyway. Sure, wpa_supplicant should provide means for the upper layer component to get enough information from the server certificate and configuration parameters in the network profile to allow those to be matches against.

Use of subject name CN for this type of purposes has been deprecated long ago even for HTTPS. As such, I'd much rather use dNSName. Anyway, I can add a new network profile configuration parameter to allow matching against any CN in the subject name (i.e., if any CN matches, the certificate is considered acceptable from this subject name filtering view point). However, even for that, there would need to be clear rules defined. Would this be suffix match? And case insensitive? Or full match as a binary comparison? Or something else?

I'd assume there could be RADIUS server setups where multiple servers are used for load balancing or high availability purposes. Those servers should be allowed to have their own, unique certificates (e.g., with CNs server1.example.com and server2.example.com). Something would need to be able to determine whether to limit future connection only to the exact same CN or to a suffix match like example.com in this specific case.

Android does not provide UI component to set any kind of matching for the server certificate (well, other than trust root). That setSubjectMatch() is documented as "substring" and as such, not really suitable for the purpose discussed in this bugzilla case.

As with DNS, this would have to be an full string match to provide proper security benefit. DNS is not case sensitive and I don't think this check has to be either.

This is what it looks like for Microsoft: http://www.mcmaster.ca/uts/connections/network/macconnect/wireless/images/vista_wpa6.png.

http://support.microsoft.com/kb/814394
"The name in the Subject line of the server certificate matches the name that is configured on the client for the connection."

This is, in my view, correct behaviour, albeit deprecated. dNSName can also be used, but can only be automatically pinned if there is only one dNSName on the certificate, and from the CAs that I know of, this still matches the CN in the subject.

If a user manually configures a server host name to connect to, multiple dNSNames on the certificate can be used. 


However, to resolve this bug, the pinning behaviour can be done either in Network Manager or wpa_supplicant.. but the subject_match functionality has to be deprecated by wpa_supplicant and at least dNSName matching has to be fixed.

If the pinning behaviour is to be done in Network Manager, wpa_supplicant needs to have an API that allows Network Manager to get the necessary information.

This is implemented in KDE plasma network-manager like this: (http://i.imgur.com/hNC50.png)
         <item>
          <widget class="KLineEdit" name="subjectMatch">
           <property name="whatsThis">
            <string>Connect only to servers whose certificate matches the given subject. Example: /CN=myvpn.company.com</string>
           </property>
          </widget>
         </item>

In android: 
https://developer.android.com/reference/android/net/wifi/WifiEnterpriseConfig.html
Indeed not in the UI, but used in WifiEnterprise configuration applications, such as the large vendor provisioning tools, as the Android UI does not allow *ANY* kind of secure connection to WPA2 enterprise networks.


Android, KDE NM and others (even including me with an Android application) implemented subject_match with the specific intent of connecting to only your organisations SPECIFIC own radius server, not ANY radius server that has a valid certificate.

In general, I'd prefer to use suffix match and that is exactly what the existing domain_suffix_match does. It does actually cover CN as well in case dNSName is not present. This was documented in the header files and deverlopers' documentation, but wpa_supplicant.conf notes did not include the details. I'm adding these there:

# domain_suffix_match: Constraint for server domain name. If set, this FQDN is
#	used as a suffix match requirement for the AAAserver certificate in
#	SubjectAltName dNSName element(s). If a matching dNSName is found, this
#	constraint is met. If no dNSName values are present, this constraint is
#	matched against SubjectName CN using same suffix match comparison.
#
#	Suffix match here means that the host/domain name is compared one label
#	at a time starting from the top-level domain and all the labels in
#	domain_suffix_match shall be included in the certificate. The
#	certificate may include additional sub-level labels in addition to the
#	required labels.
#
#	For example, domain_suffix_match=example.com would match
#	test.example.com but would not match test-example.com.


I'm not sure what you are referring to with "dNSName matching has to be fixed". altsubject_match is a full match against the specified string, e.g., altsubject_match="DNS:example.com" will require the server certificate to have at least one dNSName with "example.com" as the value. This won't match with "test-example.com" or even "test.example.com". domain_suffix_match is a suffix match that requires full label to match, i.e., domain_suffix_match="test.example.com" will match test.example.com, server1.test.example.com, but won't match example.com or foo-test.example.com.

I do not know how exactly KDE plansma network-manager works in this area (the version of NM and/or that I happen to have on this system does not have the "Connect to these Servers" item). Anyway, if that subjectMatch entry in the dialog is mapped into subject_match in wpa_supplicant network profile, that should be replaced with mapping to domain_suffix_match. IMHO, that is sufficient and better way of matching the RADIUS server as a suffix match (with full label match required). If there is a reasonable use case for which such suffix match is not sufficient, I can add a separate parameter for a full domain name match, but I'd rather not add extra complexity here unless there is a real need for it.

altsubject_match seems to have correct behaviour, but in many cases suffix match won't do.

For example, we have a certificate wireless.nikhef.nl for all wireless authentication, on all RADIUS servers. This is what clients need to verify against. This certificate is replaced annually. We also have some devices, aruba.wireless,nikhef,nl and airwave.wireless.nikhef.nl. Matching against the latter two would be incorrect behaviour.

I do agree that in terms of code, both options have valid use cases, though I  would advise network manager, android, etc to use altsubject_match over a suffix match.

This only leaves
1. Deprecating subject_match (I vote we do remove this, to avoid misleading people)
2. API that allows pinning behaviour in Network Manager, Firefox OS and Android. Thus, making dNSNames, CA and certificate hash available. Maybe the whole certificate chain, if wpa_supplicant does not know about the trust store, though this is less friendly to program against
3. GUI changes for plasma-nm and network-manager-gnome, though this is not for wpa_supplicant.

So a summary of the existing conversation is that:

1) there is no code bug in wpa_supplicant

2) there was a mis-understanding of how the various certificate verification options were used

3) wpa_supplicant documentation for domain_suffix_match was inadequate, but has been corrected upstream

4) subject_match should generally not be used except in legacy configurations

5) GUIs should allow setting altsubject_match to specify exact (eg, non-substring) matches on dNSNames, but use domain_suffix_match for substring matches on dNSNames *or* CN names

Is this a reasonable/correct summary of this bug so far?

I would say, yes, that is accurate, though I don't think subject_match should ever be used, even in legacy configurations. I cannot think of a valid use case where matching a substring in the subject would do any good, security-wise.

This misunderstanding has also spread to android, firefox OS, some GUI components and a quite significant user base. Deprecating subject_match would be advised.

Is altsubject_match="DNS:<FQDN>" (i.e., matching only against dNSName) sufficient or are there still cases where fallback to CN is needed?

I added support for domain_suffix_match with GnuTLS, but at least for now, by using the GnuTLS implementation in gnutls_x509_crt_check_hostname() which behaves a bit differently (not suffix-only, but wildcards allowed in the certificate). It is a bit unfortunate that the behavior is not identical with the comparison used with OpenSSL, but at least this should be pretty close. Anyway, that did get me thinking more about adding another parameter that would disable wildcards in GnuTLS matching and would require full match with OpenSSL, i.e., would hopefully have more or less identical behavior regardless of which of these TLS libraries is used.

Nice! Good to hear the other SSL libraries are also getting similar behaviour. :-)

Personally, I don't think it is absolutely necessary to have a CN fallback in most cases.. but according to Stefan Winter of the .lu NREN, which operates the luxembourg eduroam, there are some institutions that do this, and is technically valid (albeit deprecated). This would be the most complete solution, that would be valid in nearly all cases.

Regarding the pinning behaviour:
What would the API look like that would allow altsubject_name/CA pinning (with maybe a fingerprint fallback)? Is something like this already in place?

I added domain_match parameter which can be used to force a full case-insensitive match against dNSName, if any is included, and if not include, against any CN.

In the released wpa_supplicant versions, server certificate subject name is provided through both the ctrl_iface and D-Bus interface during authentication.
As an example, D-Bus 'Certification' signal would include subject parameter with '/C=FI/O=w1.fi/CN=server.w1.fi' format (the exact format depends on the TLS library). This signal is provided for each certificate in the server certificate chain, so the one with depth=0 would be used for this purpose.

Alternatively, special server certificate probing connection with ca_cert="probe://" could be used to get the full server certificate ('cert' parameter in that 'Certification' signal) to allow upper layer parsing and determination of what field to match against. With such information, the network profile parameters altsubject_match or domain_suffix_match could be configured to require all future connections to meet the specified matching requirements. This certificate probing mechanism would also provide certificate hash value ('cert_hash' in that D-Bus signal) that could be used to set ca_cert="hash://server/sha256/<hash>" to require that exact server certificate to be used.


In future releases (i.e., added today to hostap.git), this gets somewhat easier with following additions:

- full certificate and certificate hash are included by default even without the special certificate probe connection (i.e., you can configure normal profile and on first connection ask whether user is fine with the server certificate and then configure a suitable constraint on future connections)

- domain_match can now be used for full match against dNSName with fallback to CN

- parsed version of dNSName (and email and URI, for that matter) in SubjectAltName is provided (e.g., in D-Bus signal as 'altsubject' parameter that is an array of strings in "DNS/EMAIL/URI:<value>" format), so that upper layer software does not have to parse the certificate on its own. This is currently supported only with OpenSSL, but I guess this gets extended for GnuTLS eventually (at the same time when altsubject_match gets added; for now, GnuTLS-based build will reject any network with that parameter set)


The dbus_connect_eap test case in http://w1.fi/cgit/hostap/plain/tests/hwsim/test_dbus.py shows an example sequence that adds an EAP-TTLS/PAP profile to wpa_supplicant without a password, uses Certification signals to get the dNSName, configures dNSName constraint on the network block, and uses password request signal to provide the password when needed.

(In reply to Jouni Malinen from comment #24)
> I added domain_match parameter which can be used to force a full
> case-insensitive match against dNSName, if any is included, and if not
> include, against any CN.

Noting commit links for posterity:

http://w1.fi/cgit/hostap/commit/?id=cebee30f3170b5104a41bd27ac5f98615ed57656
http://w1.fi/cgit/hostap/commit/?id=061cbb258fced68b127f66bdd35c55f77928b720

> - parsed version of dNSName (and email and URI, for that matter) in
> SubjectAltName is provided (e.g., in D-Bus signal as 'altsubject' parameter
> that is an array of strings in "DNS/EMAIL/URI:<value>" format), so that
> upper layer software does not have to parse the certificate on its own. This
> is currently supported only with OpenSSL, but I guess this gets extended for
> GnuTLS eventually (at the same time when altsubject_match gets added; for
> now, GnuTLS-based build will reject any network with that parameter set)

http://w1.fi/cgit/hostap/commit/?id=d07d3fbda2466d1778ecdf36e2986c5d9b3c1a53
http://w1.fi/cgit/hostap/commit/?id=2099fed400bd5cd95a3e3085e16e061e466bb8c1

OK, I've backported domain_match to wpa_supplicant-2.0. It seems like that is the only wpa_supplicant change we want? (Any further work seems like it would be in NetworkManager.)

You'd probably need to add http://w1.fi/cgit/hostap/commit/?id=483dd6a5e0069d0646505c26a5194eda15472858 ('Include peer certificate always in EAP events') to make it easier for NM to figure out which certificate was used in the initial connection. http://w1.fi/cgit/hostap/commit/?id=d07d3fbda2466d1778ecdf36e2986c5d9b3c1a53 ('Add peer certificate alt subject name information to EAP events') could also be helpful, or alternatively, parse the certificate in NM which may be useful anyway if you want to make more verbose information about the server certificate (+ chain) available to the user.

I think it would be a good idea to backport the other two commits as well, so that network manager can be properly fixed as well. 

Right now, network manager is the remaining vulnerable component.

(In reply to Dan Winship from comment #26)
> OK, I've backported domain_match to wpa_supplicant-2.0. It seems like that
> is the only wpa_supplicant change we want? (Any further work seems like it
> would be in NetworkManager.)

Yeah, I think that's all we need from the supplicant.  We can track the NM parts in the upstream bug (https://bugzilla.gnome.org/show_bug.cgi?id=341323).

But yeah, the other two commits should be backported too.

Created attachment 983551 [details]
patch to dist-git with the backported fix

Patch to dist-git backporting the domain_match and cert_in_cb changes.

I've tested that this does result in wpa_supplicant emitting D-Bus signals containing the certificate info:

    NetworkManager[21601]: <info>  Certificate signal: depth=1, subject='/C=FR/ST=Radius/L=Somewhere/O=Example Inc./emailAddress=admin/CN=Example Certificate Authority', altsubject='(null)', cert_hash='8a93b5e07470d6c96b284d5107f05d2bbf937366443c1e680763e4e9ede9e3e7'
    NetworkManager[21601]: <info>  Certificate signal: depth=0, subject='/C=FR/ST=Radius/O=Example Inc./CN=Example Server Certificate/emailAddress=admin', altsubject='(null)', cert_hash='2b362debf54f31bbe948e9a925fc5d0ab0743a6f738892ee84cd625cd0b2ac5d'

The backports were relatively painless; they didn't apply completely cleanly because of other, not backported, config changes between 2.0 and master, but the fixups were simple.


I am currently considering the NetworkManager changes to NOT be part of this CVE. Since NetworkManager does not make use of subject_match, it is not vulnerable to the extension attack which this bug was initially about, and the fact that it also does not use domain_match or anything else is an existing known limitation. (Which isn't to say that we don't plan on fixing that soon, just that I don't think it counts as part of this bug.)

The part about network manager is not entirely accurate,

Network manager does support subject_match, though not via the GUI, but in the /etc/NetworkManager/system-connections profiles.

The GUI has a bigger issue.. it does not allow to check *any* kind of remote identity, other than the CA.. which clearly is not enough, because all the CA does is sign certificates.. for anyone.

If NetworkManager is not part of this CVE, we should get a new CVE for network manager..

(In reply to Wilco Baan Hofman from comment #32)
> If NetworkManager is not part of this CVE, we should get a new CVE for
> network manager..

This CVE was assigned to "wpa_supplicant subject_match incorrectly uses substring match".  However, comment 10 explains this behavior is intended and documented, making the CVE assignment invalid.  This is not to say that domain_match is undesired, only to mention that this is problematic from the CVE assignment point of view.

There is an older CVE-2006-7246, which is for NetworkManager not doing certificate check.  AFAICS, this issue was addressed in NM upstream by making it possible to configured subject_match and alt_subject_match in profile configuration files, but never exposed that setting in GUI.  Relevant upstream bug is the one linked in comment 29.  As it has not been closed, I assume those fixes were not considered complete.

Dan, what is the plan for NM upstream?  Should GUI changes be expected soon, or a config-only fix similar to existing *subject_match support today is expected first?

It seems OpenSUSE has been carrying some nm-applet GUI patch for some time:

https://build.opensuse.org/package/view_file/openSUSE:11.4:Update/NetworkManager-gnome.import5373/nma-wpa-eap-probe-ca-cert.patch
https://build.opensuse.org/package/view_file/openSUSE:Factory/NetworkManager-gnome/nm-applet-probe-radius-server-cert.patch

I'm making this bug public.  It notes the useful discussion of what led to introduction of the domain_match parameter.  Issues arising from the substring based comparison performed by subject_match are already public, e.g. via the linked NetworkManager bug in Gnome bugzilla.

The plan is to add a more flexible configuration option for NetworkManager than the existing things, and use that in the GUI instead of exposing *three* fields that all do about the same exact thing (altsubject_match, subject_match, and domain_suffix_match).

Dan Williams,

Can you elaborate a bit on what you plan to implement in Network Manager?
Because altsubject_match, subject_match, domain_suffix_match do *not* do the same thing, but I'll admit that they have the same goal in mind (identity verification from the certificate).

More flexibility in the GUI is good, as long as it defaults to a safe configuration (Which in all cases means that the dNSName/CN should be checked).

Manually verified domain_match is currently supported in wpa_supplicant. Also performed automated connection testing against wpa_supplicant-2.0-17.el7_1. Verified 0013-rh1178263-domain_match.patch and 0014-rh1178263-cert_in_cb.patch are in the source rpm and performed a rebuild to ensure the patches are applied.

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://rhn.redhat.com/errata/RHSA-2015-1090.html