Vérifiez le protocole ssl, cipher & d'autres propriétés dans un asp.net mvc 4

Les mauvaises nouvelles, tel que déterminé par ILSpy, c'est qu'il n'existe aucun moyen pour arriver à une System.Net.SslStream instance de n'importe où à l'intérieur de ASP.NET. Cette classe est utilisé pour la programmation directe contre le réseau, par exemple par la WCF cadre. Le meilleur que vous pouvez faire à partir de ASP.NET (que ce soit en utilisant le Système.Web ou OWIN sur le dessus de IIS ou HttpListener) est d'obtenir une variable de serveur (voir la liste des serveur IIS variables) pour savoir si la connexion est sécurisée par quoi que ce soit de la sécurité du transport a été négocié avec le client.

Aussi loin que la conception déterministe de la lecture des données du journal des événements lors d'une requête web... qui semble effrayant. Mais si vous pouvez le faire fonctionner, s'il vous plaît partager le code. 🙂

Sinon, vous pouvez essayer de mettre en œuvre votre propre Owin hôte (aka serveur web!) qui utilise SslStream dessous. Peut-être. 😛 Voir cet article pour une introduction détaillée à SslStream de programmation.

Mais puisque vous êtes déjà en mesure de désactiver certains protocoles sur votre serveur (comme dans cet article, je suppose)... Vous pouvez configurer votre site sur deux différents sous-domaines, par exemple www.example.com et secure.example.com, où l'ancien est à la vanille, serveur web et le dernier est configuré pour accepter les connexions TLS 1.2. Ensuite, vous devez écrire certaines initialisations logique qui obtient servi de www.example.com et essaie de faire une requête AJAX secure.example.com/securityUpgradeCheck (éventuellement avec un joliment stylisé spinner animation et "s'il vous Plaît attendre, en essayant de sécuriser cette connexion" texte pour impressionner vos utilisateurs :)). Si cette demande aboutit, l'utilisateur peut être redirigé vers secure.example.com (probablement définitivement, depuis que l'agent utilisateur est alors appelé à la prise en charge de TLS 1.2, sauf si pour une raison quelconque, l'utilisateur modifie les paramètres de son navigateur).

Pour plus d'impact, de l'ordre d'un certificat SSL EV pour le domaine sécurisé, de sorte que vos utilisateurs remarquerez la mise à jour de sécurité. 🙂

Mise à JOUR: j'ai fait un peu plus de creuser, sur la base théorique de l'écriture personnalisée (native) filtre ISAPI (ou l'extension) pour obtenir cette information via le SChannel API. Au début, j'étais plein d'espoir parce que j'ai découvert une fonction HSE_REQ_GET_SSPI_INFO qui permettrait le retour d'une SSPI CtxtHandle structure, et ce que vous pourriez appeler à partir d'une simple extension ISAPI via le EXTENSION_CONTROL_BLOCK ServerSupportFunction fonction. Que CtxtHandle structure, il s'avère, représente un SChannel contexte et peut vous obtenir une référence à un SECPKG_ATTR_CONNECTION_INFO attribut avec lequel vous pouvez récupérer la connexion SSL au niveau de l'information (les mêmes informations qui sont apparues dans les SslStream classe .NET, pour autant que je puisse dire). Toutefois, malheureusement, Microsoft prévoit que la possibilité et a décidé que cette information est uniquement disponible si vous utilisez des certificats client. Le comportement est "by design".

Il y avait un (native) SSPI fonction, QueryContextAttributes (Schannel), que j'ai découvert au cours d'une longue chasse via MSDN qui peut travail. Je n'ai pas essayé, et il n'arrive tout simplement pas de la même "by design" à la raison comme ISAPI API limitation lié ci-dessus. Toutefois, il peut être vaut la peine d'essayer. Si vous voulez explorer cette voie, voici un exemple d'une extension ISAPI. En fait, avec cette approche, vous pourriez être en mesure d'écrire un module IIS au lieu de cela, à l'aide de la plus récente IIS 7.0+ SDK.

Mais, en supposant que vous n'avez pas le luxe de la demande de certificats clients et que le plan ne fonctionne pas, qu'il ne laisse que deux options.

1. Utiliser un autre serveur web (Apache, etc...), fonctionnant sur le même physique/virtuel machine mais sur un autre port, etc. (conformément à notre discussion dans les commentaires, puisque vous ne pouvez pas faire tourner une autre machine). Si vous souhaitez donner au client un message d'information, alors cette approche, couplée avec une requête AJAX, pourrait être suffisant. Oui, un autre port peut être bloqué par un pare-feu quelque part, mais c'est seulement une option de message d'information, de toute façon.
2. Compter sur le semi-fragiles approche avec le journal des événements Système. Activer l'enregistrement des événements Schannel , puis d'écrire les journaux d'événements de l'interrogation code pour tenter de corréler la demande avec la dernière connecté événement Schannel. Notez que vous aurez besoin de trouver un moyen fiable de les corréler à ce que se trouve dans le journal des événements avec le courant de la requête HTTP, de sorte que vous pourrait également besoin d'écrire un filtre ISAPI/extension ou module IIS dans ce cas de trouver le Schannel handle de contexte (qui est ce que je suis en supposant que la corrélation serait basé sur).

Par le moyen - est votre équilibreur de charge est configuré pour toute interception SSL? Car alors toute cette chose est discutable de toute façon... Juste une pensée à considérer.

Mise à JOUR: Activation de la journalisation Schannel déduits de ce bijou:

<Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
  <System>
    <Provider Name="Schannel" Guid="{1F678132-5938-4686-9FDC-C8FF68F15C85}" /> 
    <EventID>36880</EventID> 
    <Version>0</Version> 
    <Level>4</Level> 
    <Task>0</Task> 
    <Opcode>0</Opcode> 
    <Keywords>0x8000000000000000</Keywords> 
    <TimeCreated SystemTime="2014-08-13T02:59:35.431187600Z" /> 
    <EventRecordID>25943</EventRecordID> 
    <Correlation /> 
    <Execution ProcessID="928" ThreadID="12912" /> 
    <Channel>System</Channel> 
    <Computer>**********</Computer> 
    <Security UserID="S-1-5-18" /> 
  </System>
  <UserData>
    <EventXML xmlns:auto-ns3="http://schemas.microsoft.com/win/2004/08/events" xmlns="LSA_NS">
      <Type>client</Type> 
      <Protocol>TLS 1.2</Protocol> 
      <CipherSuite>0x3c</CipherSuite> 
      <ExchangeStrength>2048</ExchangeStrength> 
    </EventXML>
  </UserData>
</Event>

Ce peuvent être lus directement à partir du code managé. Je pense que le nom d'utilisateur correspond uniquement au processus de travail IIS SID, malheureusement, mais en supposant que vous pouvez venir avec une sorte de corrélation heuristique, vous pourriez mettre en place un thread d'arrière-plan continuellement interroger le journal des événements et de vous donner une liste de récemment établi client poignées de main (l'utilisation d'un ConcurrentDictionary peut-être).

Là. C'est tout. Pas plus curieux d'enquêter pour moi. Je suis fait. 😛

Comment voulez-vous vérifier la négociation de la poignée de main TLS à partir du Serveur? a la manière d'obtenir cette sous IIS 8.5 et plus élevé dans les ASP.Net MVC /WebAPI. Au moins, il a travaillé pour moi et quelques autres, lorsque j'ai répondu hier.