https://alpaca-attack.com/

Last Checked: Jun 10, 2021, 23:34 EDT

IP Address: 172.67.147.221
ASN #: AS13335 CLOUDFLARENET, US
Location: San Francisco, California, US
URL Reputation:
  • Unknown This URL is not identified as malicious in the PhishTank Database.
  • Unknown PhishCheck thinks this URL is likely not a phish.
  • Unknown OpenPhish: URL not in feed.

Other submissions on 172.67.147.221:

Other submissions on alpaca-attack.com:

Previous checks:

                               Domain Name: alpaca-attack.com
Registry Domain ID: 2588994163_DOMAIN_COM-VRSN
Registrar WHOIS Server: whois.joker.com
Registrar URL: https://joker.com
Updated Date: 2021-06-08T21:08:56Z
Creation Date: 2021-02-03T11:47:26Z
Registrar Registration Expiration Date: 2022-02-03T11:47:26Z
Registrar: CSL Computer Service Langenbach GmbH d/b/a joker.com
Registrar IANA ID: 113
Registrar Abuse Contact Email: abuse@joker.com
Registrar Abuse Contact Phone: +49.21186767447
Domain Status: clientTransferProhibited https://icann.org/epp#clientTransferProhibited
Registrant Name: Marcus Brinkmann
Registrant Street: c/o IDPS International Domain Privacy Services GmbH
Registrant Street: Hansaallee 191
Registrant City: Duesseldorf
Registrant Postal Code: 40549
Registrant Country: DE
Registrant Phone: +49.21186767448
Registrant Fax: +49.211867676448
Registrant Email: https://csl-registrar.com/contact/alpaca-attack.com/owner
Admin Name: Marcus Brinkmann
Admin Street: c/o IDPS International Domain Privacy Services GmbH
Admin Street: Hansaallee 191
Admin City: Duesseldorf
Admin Postal Code: 40549
Admin Country: DE
Admin Phone: +49.21186767448
Admin Fax: +49.211867676448
Admin Email: https://csl-registrar.com/contact/alpaca-attack.com/admin
Tech Name: Marcus Brinkmann
Tech Street: c/o IDPS International Domain Privacy Services GmbH
Tech Street: Hansaallee 191
Tech City: Duesseldorf
Tech Postal Code: 40549
Tech Country: DE
Tech Phone: +49.21186767448
Tech Fax: +49.211867676448
Tech Email: https://csl-registrar.com/contact/alpaca-attack.com/tech
Name Server: ara.ns.cloudflare.com
Name Server: vicky.ns.cloudflare.com
DNSSEC: unsigned
URL of the ICANN Whois Inaccuracy Complaint Form: https://www.icann.org/wicf/
>>> Last update of WHOIS database: 2021-06-11T03:34:16Z <<<

For more information on Whois status codes, please visit https://icann.org/epp

NOTE: By submitting a WHOIS query, you agree to abide by the following
NOTE: terms of use: You agree that you may use this data only for lawful
NOTE: purposes and that under no circumstances will you use this data to:
NOTE: (1) allow, enable, or otherwise support the transmission of mass
NOTE: unsolicited, commercial advertising or solicitations via direct mail,
NOTE: e-mail, telephone, or facsimile; or (2) enable high volume, automated,
NOTE: electronic processes that apply to Joker.com (or its computer systems).
NOTE: The compilation, repackaging, dissemination or other use of this data
NOTE: is expressly prohibited without the prior written consent of Joker.com.


                             
  • GET
    200 OK

    https://tracking-protection.cdn.mozilla.net/allow-flashallow-digest256/1490633678

  • GET
    200 OK

    https://tracking-protection.cdn.mozilla.net/except-flashallow-digest256/1490633678

  • GET
    200 OK

    https://tracking-protection.cdn.mozilla.net/block-flash-digest256/1604686195

  • GET
    200 OK

    https://alpaca-attack.com/

  • GET
    200 OK

    https://content-signature-2.cdn.mozilla.net/chains/remote-settings.content-signature.mozilla.org-2021-07-21-15-12-54.chain

  • GET
    200 OK

    https://tracking-protection.cdn.mozilla.net/except-flash-digest256/1604686195

  • GET
    200 OK

    https://tracking-protection.cdn.mozilla.net/block-flashsubdoc-digest256/1604686195

  • GET
    200 OK

    https://tracking-protection.cdn.mozilla.net/except-flashsubdoc-digest256/1517935265

  • GET
    200 OK

    http://detectportal.firefox.com/canonical.html

  • GET
    200 OK

    http://detectportal.firefox.com/success.txt?ipv4

  • GET
    200 OK

    http://detectportal.firefox.com/success.txt?ipv6

  • GET
    200 OK

    http://detectportal.firefox.com/canonical.html

  • GET
    200 OK

    https://tracking-protection.cdn.mozilla.net/base-fingerprinting-track-digest256/89.0/1622142254

  • GET
    200 OK

    http://detectportal.firefox.com/success.txt?ipv4

  • GET
    200 OK

    http://detectportal.firefox.com/success.txt?ipv6

  • GET
    200 OK

    http://detectportal.firefox.com/canonical.html

  • GET
    200 OK

    http://detectportal.firefox.com/success.txt?ipv4

  • GET
    200 OK

    http://detectportal.firefox.com/success.txt?ipv6

  • GET
    200 OK

    https://tracking-protection.cdn.mozilla.net/base-cryptomining-track-digest256/89.0/1618956261

  • GET
    200 OK

    https://alpaca-attack.com/media/css/style.css

  • GET
    200 OK

    https://tracking-protection.cdn.mozilla.net/social-tracking-protection-facebook-digest256/89.0/1618956261

  • GET
    200 OK

    https://alpaca-attack.com/cdn-cgi/scripts/5c5dd728/cloudflare-static/email-decode.min.js

  • GET
    200 OK

    http://detectportal.firefox.com/canonical.html

  • GET
    200 OK

    http://detectportal.firefox.com/success.txt?ipv4

  • GET
    200 OK

    http://detectportal.firefox.com/success.txt?ipv6

  • GET
    200 OK

    https://tracking-protection.cdn.mozilla.net/social-tracking-protection-linkedin-digest256/89.0/1618956261

  • GET
    200 OK

    https://tracking-protection.cdn.mozilla.net/social-tracking-protection-twitter-digest256/89.0/1618956261

  • GET
    200 OK

    https://alpaca-attack.com/media/img/android-chrome-512x512.png

  • GET
    200 OK

    https://alpaca-attack.com/media/img/alpaca-overview.png

  • GET
    200 OK

    https://alpaca-attack.com/media/css/Montserrat-Bold.ttf

  • GET
    200 OK

    https://alpaca-attack.com/media/img/apple-touch-icon.png

  • GET
    200 OK

    https://alpaca-attack.com/media/img/favicon-16x16.png

b'<html lang="en"><head>\n  <meta charset="utf-8">\n  <meta http-equiv="X-UA-Compatible" content="IE=edge">\n  <meta name="viewport" content="width=device-width, initial-scale=1">\n  <meta name="description" content="">\n  <meta name="author" content="">\n  <link rel="apple-touch-icon" sizes="180x180" href="media/img/apple-touch-icon.png">\n  <link rel="icon" type="image/png" sizes="32x32" href="media/img/favicon-32x32.png">\n  <link rel="icon" type="image/png" sizes="16x16" href="media/img/favicon-16x16.png">\n  <link rel="manifest" href="media/img/site.webmanifest">\n  <meta name="theme-color" content="#ffffff">\n  <title>ALPACA Attack</title>\n  <link href="media/css/style.css" rel="stylesheet" type="text/css">\n</head>\n\n<body>\n  <header id="top">\n    <h1>ALPACA Attack</h1>\n    <div class="logo"></div>\n  </header>\n  <section id="intro">\n    <ul class="toc">\n      \n      <li><a href="#paper">Paper</a>\n      </li>\n      <li><a href="#question-answer">Q&amp;A</a></li>\n      <li><a href="libs.html">How to ALPN/SNI</a></li>\n    </ul>\n  </section>\n\n  <section>\n    <h2>News</h2>\n    <ul>\n      <li>ALPACA will be presented at <a href="https://www.blackhat.com/us-21/briefings/schedule/index.html#alpaca-application-layer-protocol-confusion---analyzing-and-mitigating-cracks-in-tls-authentication-23522">Black\n          Hat USA 2021</a> and at\n        <a href="https://www.usenix.org/conference/usenixsecurity21/presentation/brinkmann">USENIX Security Symposium\n          2021</a>.\n      </li>\n      <li>Recommended articles: <a href="https://arstechnica.com/gadgets/2021/06/hackers-can-mess-with-https-connections-by-sending-data-to-your-email-server/">Ars\n          Technica</a> (Dan Goodin),\n        <a href="https://www.golem.de/news/sicherheitsluecke-alpaca-angriff-zeigt-cross-protokoll-schwaeche-von-tls-2106-157143.html">Golem</a>\n        (Hanno B\xc3\xb6ck; German)</li>\n    </ul>\n\n    \n    <h2>Introduction</h2>\n    <p>TLS is an internet standard to secure the communication\n      between servers and clients on the internet, for example\n      that of web servers, FTP servers, and Email servers. This\n      is possible because TLS was designed to be application\n      layer independent, which allows its use in many diverse\n      communication protocols.\n    </p>\n    <p>ALPACA is an application layer protocol content confusion\n      attack, exploiting TLS servers implementing different\n      protocols but using compatible certificates, such as multi-domain\n      or wildcard certificates. Attackers can redirect traffic\n      from one subdomain to another, resulting in a valid TLS session.\n      This breaks the authentication of TLS and cross-protocol attacks\n      may be possible where the behavior of one protocol service may compromise\n      the other at the application layer.\n    </p>\n    <p>We investigate cross-protocol attacks on TLS in general and\n      conducted a systematic case study on web servers, redirecting HTTPS\n      requests from a victim\'s web browser to SMTP, IMAP, POP3, and FTP\n      servers. We show that in realistic scenarios, the attacker can\n      extract session cookies and other private user data or execute\n      arbitrary JavaScript in the context of the vulnerable web server,\n      therefore bypassing TLS and web application security.\n    </p>\n    <p>We evaluated the real-world attack surface of web browsers\n      and widely-deployed Email and FTP servers in lab experiments\n      and with internet-wide scans. We find that 1.4M web servers\n      are generally vulnerable to cross-protocol attacks, i.e., TLS\n      application data confusion is possible. Of these, 119k web servers\n      can be attacked using an exploitable application server. As a\n      countermeasure, we propose the use of the Application Layer Protocol\n      Negotiation (ALPN) and Server Name Indication (SNI) extensions in\n      TLS to prevent these and other cross-protocol attacks.\n    </p>\n    <p>Although this vulnerability is very situational and can be challenging\n      to exploit, there are some configurations that are exploitable\n      even by a pure web attacker. Furthermore, we could only analyze\n      a limited number of protocols, and other attack scenarios may exist.\n      Thus, we advise that administrators review their deployments and\n      that application developers (client and server) implement\n      countermeasures proactively for all protocols.\n    </p>\n\n    <h2>Attack Overview</h2>\n\n    <img src="media/img/alpaca-overview.png">\n    <p>The image shows three possible ways for an attacker to use\n      cross-protocol attacks against webservers, exploiting vulnerable\n      FTP and Email servers: In the Upload Attack, the attacker exfiltrates authentication cookies or other private\n      data.\n      In the Download Attack, the attacker executes a stored XSS attack.\n      In the Reflection Attack, the attacker executes a reflected\n      XSS in the context of the victim website.\n    </p>\n\n    <h2 id="paper">Full Technical Paper (last update: 2021-06-09)</h2>\n    <p><a href="ALPACA.pdf">ALPACA: Application Layer Protocol\n        Confusion-Analyzing and Mitigating Cracks in TLS\n        Authentication</a>, Marcus Brinkmann, Christian Dresen, Robert\n      Merget, Damian Poddebniak, Jens M\xc3\xbcller, Juraj Somorovsky, J\xc3\xb6rg\n      Schwenk, Sebastian Schinzel.\n    </p>\n    <p>The artifacts are available at\n      <a href="https://github.com/RUB-NDS/alpaca-code/">GitHub</a>.</p>\n\n\n    <h2 id="question-answer">FAQ</h2>\n\n    <h3>I am an admin, should I drop everything and fix this?</h3>\n\n    <p>Probably not. For the ALPACA attack to succeed, many\n      preconditions need to be fulfilled. The generic attack\n      requires a MitM attacker that can intercept and divert the\n      victim\'s traffic at the TCP/IP layer. However, if you run\n      application servers such as FTP and email on non-standard\n      ports that are not blocked by browsers, you should make sure\n      that you are not vulnerable to the web attacker variant of\n      ALPACA that can affect users of Internet Explorer.</p>\n\n    <h3>What can the attackers gain?</h3>\n\n    <p>For the specific attacks on HTTPS described in the paper,\n      the attacker can potentially steal cookies or perform a cross-site\n      scripting attacks.</p>\n\n    <p>However, the potential consequences to the general ALPACA attack are\n      dependent on the interactions of two unknown protocols, so any number\n      of undesirable behaviors may be possible.\n    </p>\n\n    <h3>Who is vulnerable?</h3>\n    <p>This is difficult to answer. The general flaw behind ALPACA\n      is within the server authentication of TLS, so potentially all TLS servers\n      are affected that have compatible certificates with other TLS services.\n      In regards to that, all those servers have to be considered vulnerable.\n      However, for practical purposes, this definition is not very useful, as the\n      flaw is exploitable only in some cases. We therefore distinguish between\n      vulnerable servers and exploitable services. Our analysis was limited\n      to only a few protocols and a small number of implementations, so we\n      can really only make clear statements for those. From our analysis, the\n      following is generally true:</p>\n\n    <ul>\n      <li>Sharing certificates between a Webserver and an FTP server is almost\n        always dangerous if an attacker has write access to the FTP server.\n        It is sometimes dangerous if the attacker has no write access.</li>\n      <li>Sharing certificates between a Webserver and an SMTP/POP3/IMAP server\n        is sometimes dangerous, depending on the exact behavior of the server.</li>\n    </ul>\n\n    <p>Here is a list of analyzed implementations in regards to their vulnerability (see Table 3 in the paper):\n      Sendmail SMTP allowed reflection attacks that work in Internet Explorer when\n      used over STARTTLS. Cyrus, Kerio Connect and Zimbra IMAP servers allowed\n      download and reflection attacks that work in Internet Explorer. Courier,\n      Cyrus, Kerio Connect and Zimbra allowed download attacks that work in Internet Explorer. Microsoft IIS, vsftpd,\n      FileZilla Server and Serv-U FTP servers allowed reflection attacks that work in Internet Explorer. And the same\n      FTP servers allowed upload and download attacks that work in all browsers.</p>\n\n    <p>But even then there are interactions with analyzed and not yet analyzed\n      protocols which makes a risk estimation difficult, since we believe that\n      there is a large number of yet undiscovered vulnerabilities in this area.</p>\n\n    <p>Browsers are generally affected by the vulnerability, but they are not\n      responsible for the flaw. We found that some browsers are more vulnerable\n      than others because of how they react to non-HTTP responses.</p>\n\n    <h3>So how practical is the attack?</h3>\n    <p>Most attacks require an active Man-in-the-Middle attacker, that means some way\n      for an attacker to intercept and modify the data sent from the victim\xe2\x80\x99s browser\n      to the web server. This is difficult on the Internet, but can be a plausible\n      attacker model on the local network. Also, some attack variations do not\n      require a Man-in-the-Browser, and thus are more dangerous. In particular,\n      if you are still using Internet Explorer, we recommend you update to the\n      latest version from June 8th, 2021.</p>\n\n    <h3>Is my website/ftp-server/mail-server vulnerable?</h3>\n\n    <p>It might be. If you are hosting several TLS-enabled application servers\n      on the same hostname, or if you use multi-domain certificates, or if you\n      use wild-card certificates, you may be vulnerable to the general\n      confusion attack. If one of the application servers you are hosting\n      has an exploitable upload, download, or reflection vector, this may\n      negatively impact the security of your webserver.</p>\n\n    <h3>Is my browser/client vulnerable?</h3>\n\n    <p>Internet Explorer and Edge Legacy (i.e., those <emph>not</emph> based on Chrome)\n      are "more" vulnerable than other browsers, because they block fewer ports and\n      perform content-sniffing. Content-sniffing is dangerous, because it enables\n      JavaScript code execution in server responses that are noisy due to error\n      messages by the application server that implements a protocol different\n      from HTTP. This means that the pure web attacker variant of ALPACA is more\n      dangerous for users of such browsers than for other users.</p>\n    <p>However, no browser protects the user against all possible ALPACA attacks.\n      In particular, all browsers can be compromised by a Man-in-the-Middle attacker\n      who has write-access to an error-tolerant FTP server presenting a certificate\n      compatible with a target web server under attack. Although the FTP server can\n      in theory protect against this particular attack by detecting HTTP POST requests\n      and/or terminating the connection after a small number of errors, this attack\n      variant shows that this is not a bug in the browser, the web server, or the\n      application server, but an emergent property of the TLS landscape.</p>\n\n    <h3>Is this a new attack?</h3>\n    <p>The ALPACA attack is not fundamentally new. Cross-protocol\n      attacks on HTTP were first described by Jochen Topf (2001),\n      and Jann Horn presented the first attack on a TLS-secured HTTP\n      connection in 2014 involving ProFTPD. We did the first systematic\n      study for cross-protocol attacks against the browser exploiting\n      popular SMTP, IMAP, POP3, and FTP servers, performed an\n      internet-wide scan to estimate the number of affected web\n      servers, and generalized the attack away from a browser-specific\n      issue to a general property of misconfigured TLS servers. We\n      think that this new perspective is useful in focussing countermeasures\n      on a limited number of effective options, rather than patching\n      application servers one at a time as more exploits are found.</p>\n\n    <h3>Why does TLS not protect the TCP connection endpoints?</h3>\n    <p>The ALPACA attack is only possible because TLS does not protect the source\n      or destination IP and port address of the TCP connection. As is stated\n      in the TLS RFC, TLS is application layer independent. However, this gap\n      in protection gives the attacker the flexibility to redirect traffic\n      from one server to another. If the presented certificate of the\n      substitute server is compatible with that of the intended server,\n      the general content confusion attack is possible (although it\n      depends on the server and client behavior if it can actually\n      be exploited).</p>\n\n    <h3>Can TLS mitigate these attacks at all?</h3>\n\n    <p>Two extensions in TLS can provide some protection to the application layer\n      protocol: SNI and ALPN. With SNI, the client can let the server know about\n      the hostname it wants to connect to, which is useful in virtual hosting\n      configurations. Sadly, SNI is often misconfigured with an insecure fallback\n      to a default server, allowing content confusion attacks (for HTTP, these\n      were analyzed by Delignat et al. in 2015, and Zhang et al. in 2020).\n      However, the SNI standard allows the server to terminate the connection\n      if the hostname does not match the expected hostname of the server,\n      which would prevent some ALPACA attacks in practice. Unfortunately,\n      this strict behavior is rarely implemented, even among web servers.</p>\n\n    <p>For application servers, which commonly lag behind web servers in\n      feature completeness with regards to TLS, the situation is even more\n      dire. With ALPN, the client can let the server know about the intended\n      protocol, which is used to demultiplex between HTTP/1.x and HTTP/2\n      connections to a web server without requiring an additional roundtrip.\n      Here the standard mandates strict behavior, so a server supporting ALPN\n      should terminate the connection if no supported protocol is requested\n      by the client. Unfortunately, this strict behavior is commonly not\n      implemented, and many application servers do not even support the ALPN extension\n      at all.</p>\n\n    <h3>Why is the attack called "ALPACA"?</h3>\n\n    <p>We initially were interested in special properties of the\n      HTTP, FTP and email protocols that make cross-protocols\n      practical. However, we eventually realized that the ALPACA\n      attack is generic, and that the authenticity of the TLS\n      connection is already compromised before any application\n      layer data is exchanged. So, the original acronym\n      ("Application Layer Protocols Allowing Cross-Protocol Attacks")\n      was not a good fit anymore, because it is not the ALP allowing\n      the attack, but the insufficiency of TLS to protect the TCP\n      connection endpoints. Still, the name stuck, and we managed\n      to squeeze the letters in the title in the following way:\n      "Application Layer Protocol Confusion - Analyzing and mitigating\n      Cracks in tls Authentication". Tortured, we know.\n      But ALPACAs are still cute. :)</p>\n\n    <h3>How have vendors responded to this vulnerability?</h3>\n\n    <p>Many vendors have updated their application servers to remove exploitation\n      vectors or add countermeasures in the application layer and/or TLS implementation.\n      TLS library maintainers have reviewed the ALPN and SNI implementations and\n      updated their code and documentation to allow easy implementation of\n      countermeasures by developers. To prevent the attacks in the pure browser\n      attacker model, browser vendors have blocked more standard application ports\n      and disabled content-sniffing in more scenarios.</p>\n    <p>Specific responses are listed below (please contact us if you have more info!):</p>\n    <ul>\n      <li>Microsoft Internet Explorer blocked more non-HTTP server ports and disabled content sniffing for HTTP requests\n        to non-standard ports (<a href="https://msrc.microsoft.com/update-guide/vulnerability/CVE-2021-31971">CVE-2021-31971</a>).</li>\n      <li>\n        Sendmail fixed a bug to detect HTTP requests when STARTTLS is used, and since Sendmail 8.17 there are additional\n        countermeasures at the application layer to block HTTP requests.</li>\n      <li>Courier 5.1.0 implemented support for ALPN.</li>\n      <li>FileZilla implemented countermeasures at the application and TLS layer.</li>\n      <li>Vsftpd 3.0.4 implemented countermeasures at the application and TLS layer.</li>\n      <li>Nginx 1.21.0 implemented mitigations at the application layer in the mail proxy.</li>\n      <li>crypto/tls (Go) now <a href="https://github.com/golang/go/commit/90d6bbbe42c15d444c1da0a1c293192d6f735a8e">enforces ALPN overlap</a>\n        when negotiated on both sides.</li>\n    </ul>\n\n\n    <h3>How is this attack related to other TLS attacks?</h3>\n    <p>ALPACA uses the same attacker scenario as other TLS attacks,\n      i.e. it assumes a Man-in-the-Middle attacker who can lure a\n      victim to an attacker-controlled web site. However, in the\n      ALPACA attack, we do not try to attack the cryptographic\n      protections of TLS directly. Instead, we exploit defects\n      in the configuration of TLS services, who often share\n      certificates to save costs, reduce administrative work,\n      or enable reverse proxy deployments where several services\n      share a single, terminating TCP endpoint. In contrast to other\n      TLS attacks, the attacker never compromises the confidentiality\n      of the TLS connection. However, due to misconfiguration,\n      authenticity and integrity are affected, allowing the attacker\n      to inject some dangerous data into the connection, while\n      the victim remains oblivious to the attack.</p>\n\n    <h3>What about other protocols?</h3>\n\n    <p>The ALPACA attack is generic, i.e. it describes the preconditions\n      under which TLS traffic from the client to one server implementing\n      one protocol can be redirected to another server implementing a\n      different protocol, which can lead to any number of undesirable\n      behavior or security vulnerabilities. We only looked at the\n      combination of a HTTP client with an SMTP, IMAP, POP3, or FTP\n      application server. We did not investigate any of the other\n      hundreds of possible cross-protocol scenarios possible with\n      current TLS enabled applications and servers. In addition,\n      as TLS is more widely deployed, more protocols will be added\n      to the TLS landscape, increasing the possibility of ALPACA\n      attacks quadratically with the number of protocols and applications.</p>\n    <p>If you find application layer protocol confusion attacks in other protocols,\n      let us know! We are of course very interested in hearing about other\n      affected protocols and applications.</p>\n\n    <h3>If my clients and servers verify the ALPN and SNI parameters of the TLS handshake, will I be secure against\n      this attack?</h3>\n    <p>We do not think that it is feasible for clients or servers to enforce\n      the use of ALPN and SNI for a long time, because doing so will exclude\n      legacy clients and servers that have not been updated yet, and it is\n      unlikely that this will be accepted by users or service providers.\n      However, if both client and server support ALPN, and make sure that\n      an acceptable protocol and hostname is negotiated, they will protect\n      connections to all other servers with compatible certificates by\n      the same client from almost all content confusion attacks.</p>\n    <p>However, there still is some room for content confusion attacks\n      even with ALPN and SNI fully deployed. If two services implement\n      the same protocol on the same host, but on a different port,\n      connections to one server can be redirected to another by an attacker.\n      This can enable same-protocol, same-host context confusion attacks\n      similar to those described by Delignat et al. (2015) and Zhang et al. (2020)\n      in very specific scenarios.</p>\n\n    <h3>Is this vulnerability really serious enough to deserve a name, a logo and a web page?</h3>\n\n    <p>ALPACA is not a simple software bug that can be fixed with an update\n      to a single library or component. Instead, clients and servers need\n      to be updated to protect the connections to other (seemingly unrelated)\n      servers. This means we need to raise awareness of the issue across all\n      TLS-enabled applications and protocols, which is a huge effort. We expect\n      that the general ALPACA attack will stay with us for many years, so we\n      have a cute animal to keep us company while we help clients and servers\n      to adopt the suggested countermeasures!</p>\n\n    <h3>How can I contact you?</h3>\n\n    <p>You can reach us via mail or twitter:</p>\n    <ul>\n      <li>Marcus Brinkmann, Ruhr University Bochum, <a href="https://twitter.com/lambdafu">@lambdafu</a>,\n        marcus.brinkmann@rub.de</li>\n      <li>Christian Dresen, M\xc3\xbcnster University of Applied Sciences, <a href="https://twitter.com/dr4ys3n">@dr4ys3n</a>,\n        c.dresen@fh-muenster.de</li>\n      <li>Robert Merget, Ruhr University Bochum, <a href="https://twitter.com/ic0nz1">@ic0nz1</a>, robert.merget@rub.de\n      </li>\n      <li>Damian Poddebniak, M\xc3\xbcnster University of Applied Sciences, <a href="https://twitter.com/dues__">@dues__</a>,\n        poddebniak@fh-muenster</li>\n      <li>Jens M\xc3\xbcller, Ruhr University Bochum, <a href="https://twitter.com/jensvoid">@jensvoid</a>,\n        jens.a.mueller@rub.de</li>\n      <li>Juraj Somorovsky, Paderborn University, <a href="https://twitter.com/jurajsomorovsky">@jurajsomorovsky</a>,\n        juraj.somorovsky@upb.de</li>\n      <li>J\xc3\xb6rg Schwenk, Ruhr University Bochum, <a href="https://twitter.com/JoergSchwenk">@JoergSchwenk</a>,\n        joerg.schwenk@rub.de</li>\n      <li>Sebastian Schinzel, M\xc3\xbcnster University of Applied Sciences, <a href="https://twitter.com/seecurity">@seecurity</a>, schinzel@fh-muenster</li>\n    </ul>\n\n    <h3>Responsible Disclosure Timeline</h3>\n    <ul>\n      <li>2020-10-20: Initial contact with Eric Rescorla (author of TLS standard, CTO of Mozilla)</li>\n      <li>2020-12-03: Initial contact with OpenSSL.</li>\n      <li>2021-02-02: Initial contact with other TLS library maintainers.</li>\n      <li>2021-02-20: Initial contact with all affected application servers (FTP, Email).</li>\n      <li>2021-03-25: Initial contact with nginx and Apache.</li>\n      <li>2021-06-09: Public disclosure.</li>\n    </ul>\n\n  </section>\n  <footer>\n    <p class="text-muted">Last updated 2021-06-09. The ALPACA\n      website is free to use under\n      a <a href="//creativecommons.org/publicdomain/zero/1.0/">CC0</a>\n      license. Web design by <a href="http://sarahmadden.com/">Sarah\n        Madden</a> and Christian Dresen.\n      Adapted for Alpaca by Marcus Brinkmann.\n      The ALPACA logo was designed\n      by <a href="https://www.fiverr.com/tnhs_project">tnhs_project</a>.\n      | <a href="imprint.html">Imprint</a></p>\n  </footer>\n\n\n</body></html>'

                             

Screenshot: