Planet Collab

🔒
❌ About FreshRSS
There are new available articles, click to refresh the page.
Today — August 10th 2020Your RSS feeds

Flask Python SQLite AWS EC2 nginx gunicorn

By Web Maxtor
Moving a Flask Python and SQLite application from a Windows desktop to Amazon EC2 instance running nginx and gunicornAfter adding a Webex Teams BOT function to a small team performance tracking application I created it was essentially a requirement to move it to a public server with a fixed IP address / DNS name. To keep it low cost and simple I chose to use a free-tier Amazon AWS EC2 instance
  • August 10th 2020 at 01:00
Before yesterdayYour RSS feeds

RFC 8807: Login Security Extension for the Extensible Provisioning Protocol (EPP)

By Stéphane Bortzmeyer

Le protocole EPP d'avitaillement de ressources (par exemple de noms de domaine) a un mécanisme de sécurité très simple, à base de mots de passe indiqués lors de la connexion. Ce mécanisme avait plein de limitations ennuyeuses, dans le RFC original, et ce nouveau RFC vise à les réduire.

L'authentification dans EPP est décrite dans le RFC 5730, section 2.9.1.1 (voir aussi sa section 7). Le client EPP envoie un mot de passe, qui doit faire entre 6 et 16 caractères (cf. le type pwType dans le schéma XSD du RFC 5730, section 4.1). Le client peut changer son mot de passe en indiquant un nouveau en EPP. En outre, la session EPP est typiquement portée sur TLS, ce qui assure la confidentialité du mot de passe, et la possibilité d'ajouter une authentification par le biais d'un certificat client. Mais c'est tout. Le RFC 5730 ne permet pas de mot de passe plus long, ne permet pas au client de savoir combien de tentatives erronées ont eu lieu, ne permet pas d'indiquer l'expiration d'un mot de passe (si ceux-ci ont une durée de vie limitée) et ne permet pas au serveur EPP d'indiquer, s'il refuse un nouveau mot de passe, pourquoi il le juge invalide.

Cette extension à EPP figure désormais dans le registre des extensions, créé par le RFC 7451.

Notre RFC ajoute donc plusieurs nouveaux éléments XML qui peuvent apparaitre en EPP (section 3). D'abord, la notion d'évènement. Un évènement permet d'indiquer, dans un élément <event> :

  • l'expiration d'un mot de passe,
  • l'expiration du certificat client,
  • la faiblesse d'un algorithme cryptographique,
  • la version de TLS, par exemple pour rejeter une version trop basse,
  • les raisons du rejet d'un nouveau mot de passe (« le mot de passe doit comporter au moins une majuscule, une minuscule, un chiffre arabe, un chiffre romain, une rune et un hiéroglyphe », et autres règles absurdes mais fréquentes),
  • des statistiques de sécurité, comme le nombre de connexions refusées suite à un mot de passe incorrect.
En utilisant loginSec comme abréviation pour l'espace de noms de l'extension EPP de ce RFC, urn:ietf:params:xml:ns:epp:loginSec-1.0, voici un exemple d'évènement, indiquant qu'il faudra bientôt changer de mot de passe :

 <loginSec:event
     type="password"
     level="warning"
     exDate="2020-04-01T22:00:00.0Z"
     lang="fr">
     Le mot de passe va bientôt expirer.
</loginSec:event>

  
On pourrait voir aussi cet évènement indiquant le nombre de connexions ratées, ce qui peut alerter sur une tentative de découverte du mot de passe par force brute :

<loginSec:event
     type="stat"
     name="failedLogins"
     level="warning"
     value="100"
     duration="P1D"
     lang="fr">
     Trop de connexions ratées.
</loginSec:event>

  

Si on utilise des mots de passe qui suivent les nouvelles règles, il faut l'indiquer en mettant dans l'ancien élément <pw> la valeur [LOGIN-SECURITY]. Si elle est présente, c'est qu'il faut aller chercher le mot de passe dans le nouvel élément <loginSec:pw> (idem pour un changement de mot de passe).

La section 4 du RFC donne les changements pour les différentes commandes EPP. Seule <login> est concernée. Ainsi, <login> gagne un élément <loginSec:userAgent> qui permet d'indiquer le type de logiciel utilisé côté client. Mais le principal ajout est évidemment <loginSec:pw>, qui permet d'utiliser les mots de passe aux nouvelles règles (mots de passe plus longs, par exemple). Il y a aussi un <loginSec:newPw> pour indiquer le nouveau mot de passe à utiliser. Notez que, si le mot de passe comprend des caractères Unicode, il est recommandé qu'ils se conforment au RFC 8265 (profil OpaqueString).

Voici un exemple d'une commande <login> nouveau style :


<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
  <command>
    <login>
      <clID>ClientX</clID>
      <pw>[LOGIN-SECURITY]</pw>
      ...
    </login>
    <extension>
      <loginSec:loginSec
        xmlns:loginSec=
          "urn:ietf:params:xml:ns:epp:loginSec-1.0">
        <loginSec:userAgent>
          <loginSec:app>EPP SDK 1.0.0</loginSec:app>
          <loginSec:tech>Vendor Java 11.0.6</loginSec:tech>
          <loginSec:os>x86_64 Mac OS X 10.15.2</loginSec:os>
        </loginSec:userAgent>
        <loginSec:pw>this is a long password not accepted before</loginSec:pw>
      </loginSec:loginSec>
    </extension>
    ...
  </command>
</epp>

  
Et une réponse positive du serveur EPP à cette connexion, mais qui avertit que le mot de passe va expirer le 1er juillet :

<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
  <response>
    <result code="1000">
      <msg>Command completed successfully</msg>
    </result>
    <extension>
      <loginSec:loginSecData
        xmlns:loginSec=
          "urn:ietf:params:xml:ns:epp:loginSec-1.0">
        <loginSec:event
          type="password"
          level="warning"
          exDate="2020-07-01T22:00:00.0Z"
          lang="en">
          Password expiring in a week
        </loginSec:event>
      </loginSec:loginSecData>
    </extension>
    ...
  </response>
</epp>

 
Et, ici, lorsqu'un client a voulu changer son mot de passe expiré, avec <loginSec:newPw>, mais que le nouveau mot de passe était trop simple (cf. les recommandations de l'ANSSI) :

<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
  <response>
    <result code="2200">
      <msg>Authentication error</msg>
    </result>
    <extension>
      <loginSec:loginSecData
        xmlns:loginSec=
          "urn:ietf:params:xml:ns:epp:loginSec-1.0">
        <loginSec:event
          type="password"
          level="error"
          exDate="2020-03-24T22:00:00.0Z">
          Password has expired
        </loginSec:event>
        <loginSec:event
          type="newPW"
          level="error"
          lang="fr">
          Mot de passe vraiment trop trivial.
        </loginSec:event>
      </loginSec:loginSecData>
    </extension>
    ...
  </response>
</epp>

 

Le schéma complet figure dans la section 5 du RFC.

Un changement plus radical aurait été de passer à un cadre d'authentification plus général comme SASL (RFC 4422) mais l'IETF a choisi une évolution plus en douceur.

À l'heure actuelle, je ne connais que deux mises en œuvre de ce RFC, dans le SDK de Verisign, en https://www.verisign.com/en_US/channel-resources/domain-registry-products/epp-sdks et dans le logiciel libre Net::DRI. Apparemment, aucun serveur EPP de « grand » registre n'annonce l'extension, à part Verisign.

  • August 8th 2020 at 02:00

Python Tuples/Lists to DataFrame using Pandas

By italchemy

Here I am trying to convert data collected from a user input and converting them into a pandas dataframe.

 

import pandas as pd

sw_1 = (‘000ABC111DAB’, ‘SW01’, ‘172.10.1.1’, ‘WS-C3850-12X48U’, ‘SW’)
sw_2 = (‘000ABC111DAC’, ‘SW02’, ‘172.10.1.2’, ‘WS-C3850-12X48U’, ‘SW’)
sw_3 = (‘000ABC111DE3’, ‘SW03’, ‘30.30.30.1’, ‘WS-C3850-12X48U’, ‘SW’)
sw_4 = (‘000ABC111DE4’, ‘SW04’, ‘40.40.40.1’, ‘WS-C3850-12X48U’, ‘SW’)
sw_5 = (‘000ABC111DE5’, ‘SW05’, ‘50.50.50.1’, ‘WS-C3850-12X48U’, ‘SW’)

device_columns = [“SERIAL_NUMBER”, “HOSTNAME”, “IP_ADDRESS”, “DEVICE_MODEL”, “DEVICE_TYPE”]
sws = [sw_1, sw_2, sw_3, sw_4, sw_5]

x = pd.DataFrame(columns = device_columns, data = sws)
print(x)

 

tuple to dataframe

Get Root Access to CUCM, CUC, UCCX just like TAC in less than a minute

By Avinash Karnani

Get Root Access to CUCM, Cisco Unity Connection, UCCX just like Cisco TAC in less than a minute.

Most of you might know that we can root Cisco Unified Communications Manager (CUCM), Cisco Unity Connection (CUC) or Cisco Unified Contact Center Express (UCCX) using CentOS or Linux OS. That is a long process  where you need to shutdown the platform, boot the platform with CentOS or Linux and then root it using some commands and then turn on the platform. This  is time consuming and it takes around 15-30 minutes. In case you have not gone through this process, here is the article.

CUCM, Cisco Unity Connection, UCCX Root Access

Note: UC Collabing does not recommend to try and apply it on your production server and will not be held for any damages that could occur in your system. In case you perform this on your production servers, you may void Cisco contract. This is only for lab and learning purpose!

Pre-requisite – Download UCOS Password Decrypter from this link.

Here is the step by step process to root your UC Appliance.

  • Login to CUCM/UCCX/CUC which you want to get root access using SSH.
  • Enter the command : utils remote_account enable
  • You should receive a message as “Successful in enabling RemoteSupport“.
  • Enter the command : utils remote_account create rootuser 30  (The remote account name will be “rootuser” and it will be valid for 30 days only)
  • You should receive a message as “Account Successfully created“.uccollabing.com
  • Launch UCOS Password Decryptor tool.
  • Click on Tools > Click on Decode Passphrase

uccollabing.com

uccollabing.com

  • Now copy the Passphrase which was generated from the CLI and enter it into Remote Support Passphrase.uccollabing.com
  • Now open a new Putty session and login to the CUCM/CUC/UCCX CLI which you used in the above steps.
  • Login with username as “rootuser” and password as generated in he Decoded Password. In our example it is “HP1LPBIFJ4

uccollabing.com

After 30 days you can follow the process again and gain access.

HTH

The post Get Root Access to CUCM, CUC, UCCX just like TAC in less than a minute appeared first on UC Collabing.

Cisco – Python Fundamentals example Gi0/1

By italchemy

>> if_state = [“Gi0/1”, [{“state”: “shutdown”}]]
>>> if_state[1]
[{‘state’: ‘shutdown’}]
>>> if_state[1][0]
{‘state’: ‘shutdown’}
>>> if_state[1][0][“state”]
‘shutdown’

 

>> ios_xe = {“csr1kv1”: {“os”:”ios-xe”, “version”:”16.09.03″}, “if_state”: [{“name”: “Gi0/1”, “state”:”shutdown”}]}

>>> ios_xe[“csr1kv1”]
{‘os’: ‘ios-xe’, ‘version’: ‘16.09.03’}
>>> ios_xe[“if_state”]
[{‘name’: ‘Gi0/1’, ‘state’: ‘shutdown’}]
>>> ios_xe[“csr1kv1”][“os”]
‘ios-xe’
>>> ios_xe[“csr1kv1”][“version”]
‘16.09.03’

>>> ios_xe[“if_state”][0]
{‘name’: ‘Gi0/1’, ‘state’: ‘shutdown’}
>>> ios_xe[“if_state”][0][“name”]
‘Gi0/1’
>>> ios_xe[“if_state”][0][“state”]
‘shutdown’

 

 

 

 

How UCaaS Leads to Better Customer Service

Employing UCaaS technology in your business may seem like a great choice to save money by offering predictable telecommunication costs, reducing onsite hardware and maintenance, and switching from capital expenditures to operational expenditures. The features in this new technology can also be used to provide better customer service.

Python Tuples/Lists to DataFrame using Pandas

By italchemy

Here I am trying to convert data collected from a user input and converting them into a pandas dataframe.

 

import pandas as pd

sw_1 = (‘000ABC111DAB’, ‘SW01’, ‘172.10.1.1’, ‘WS-C3850-12X48U’, ‘SW’)
sw_2 = (‘000ABC111DAC’, ‘SW02’, ‘172.10.1.2’, ‘WS-C3850-12X48U’, ‘SW’)
sw_3 = (‘000ABC111DE3’, ‘SW03’, ‘30.30.30.1’, ‘WS-C3850-12X48U’, ‘SW’)
sw_4 = (‘000ABC111DE4’, ‘SW04’, ‘40.40.40.1’, ‘WS-C3850-12X48U’, ‘SW’)
sw_5 = (‘000ABC111DE5’, ‘SW05’, ‘50.50.50.1’, ‘WS-C3850-12X48U’, ‘SW’)

device_columns = [“SERIAL_NUMBER”, “HOSTNAME”, “IP_ADDRESS”, “DEVICE_MODEL”, “DEVICE_TYPE”]
sws = [sw_1, sw_2, sw_3, sw_4, sw_5]

x = pd.DataFrame(columns = device_columns, data = sws)
print(x)

 

tuple to dataframe

Decrypt CUCM UCCX CUC Cluster Security Password or Web Admin Password

By Avinash Karnani

How to decrypt CUCM/CUC/UCCX Security Password, Admin Password, App User Password, SFTP password in less than 5 mins.

There are some cases observed where you don’t have the cluster security credentials information documented properly when you installed Cisco Unified Communications Manager (CUCM) or Cisco Unity Connection (CUC) or Cisco Unified Contact Center Express (UCCX). This is mostly used when you are trying to add a node in your UC environment to expand the UC Cluster.

With the given tool, you don’t even need to restart your cluster and you could get the CUCM or CUC or UCCX Security Credentials and Web Admin Password with ease.

How to get the CUCM/CUC/UCCX security password or Web Admin Password?

  • Login to CUCM/CUC/UCCX CLI.
  • Run the command “utils create report platform“. This will create a TAR file in the platform/log/ directory. This needs to be downloaded using SFTP software like FreeFTPD.

    uccollabing.com

  • Once the file is downloaded, you need to use some tools like 7zip to extract the XML file i.e., platformConfig.xml.

    uccollabing.com

  • Download UCOS Password Decryptor from the link here.
  • Launch the UCOS Password Decryptor tool which you downloaded from the above link.

    uccollabing.com

  • Platform Config File > Click on Select File and choose the platformConfig.xml file you downloaded from CUCM/CUC/UCCX.

    uccollabing.com

Now you can see that it gives you Cluster Security Password, SFTP Password, App Username and Password, Local Admin Password.

HTH

The post Decrypt CUCM UCCX CUC Cluster Security Password or Web Admin Password appeared first on UC Collabing.

RFC 4253: The Secure Shell (SSH) Transport Layer Protocol

By Stéphane Bortzmeyer

Le protocole SSH de sécurité est composé de plusieurs parties, spécifiées dans des RFC différents. Ici, il s'agit de la couche basse de SSH, située juste au-dessus de TCP, et en dessous de protocoles qui permettent, par exemple, la connexion à distance. Cette couche basse fournit l'authentification (de la machine, pas de l'utilisateur) et la confidentialité, via de la cryptographie.

Le principe général de cette partie de SSH est classique, et proche de celui d'autres protocoles de cryptographie comme TLS (RFC 4251 pour une vue générale de l'architecture de SSH). Le client établit une connexion TCP avec le serveur puis chaque partie envoie une liste des algorithmes utilisés pour l'authentification, l'échange de clés et le chiffrement ultérieur. Une fois un accord trouvé, le serveur est authentifié, typiquement par de la cryptographie asymétrique, comme ECDSA. Un mécanisme d'échange de clés comme Diffie-Hellman permet de choisir des clés partagées qui serviront pour les opérations de chiffrement symétrique (par exemple avec AES) qui chiffreront tout le reste de la communication. Ce processus de négociation fournit l'agilité cryptographique (RFC 7696). Du fait de cette agilité, la liste des algorithmes utilisables n'est pas figée dans les RFC. Démarrée par le RFC 4250, sa version à jour et faisant autorité est à l'IANA.

Notez que j'ai simplifié le mécanisme de négociation : il y a d'autres choix à faire dans la négociation, comme celui de l'algorithme de MAC. Les autres fonctions de SSH, comme l'authentification du client, prennent place ensuite, une fois la session de transport établie selon les procédures définies dans notre RFC 4253.

L'établissement de connexion est normalisé dans la section 4 du RFC. SSH suppose qu'il dispose d'un transport propre, acheminant des octets sans les modifier et sans les interpréter. (TCP répond à cette exigence, qui est très banale.) Le port par défaut est 22 (et il est enregistré à l'IANA, lisez donc le récit de cet enregistrement). En pratique, il est fréquent que SSH utilise d'autres ports, par exemple pour ralentir certaines attaques par force brute (OpenSSH rend cela très simple, en indiquant dans son ~/.ssh/config le port du serveur où on se connecte). Une fois la connexion TCP établie, chaque machine envoie une bannière qui indique sa version de SSH, ici la version 2 du protocole (la seule survivante aujourd'hui) et la version 7.6 de sa mise en œuvre OpenSSH :

% telnet localhost 22
...
SSH-2.0-OpenSSH_7.6p1 Ubuntu-4ubuntu0.3
  
Un établissement de session complet comprend :
  • Connexion TCP,
  • envoi des bannières (qui peut être fait simultanément par le serveur et le client, pas besoin d'attendre l'autre),
  • début de la procédure d'échange de clés (KEX, pour Key EXchange) avec les messages SSH_MSG_KEXINIT (qui peuvent aussi être envoyés simultanément),
  • échange de clés proprement dit, par exemple avec des messages Diffie-Hellman.
Comme certains messages peuvent être envoyés en parallèle (sans attendre l'autre partie), il est difficile de compter combien d'aller-retours cela fait. (Optimiste, le RFC dit que deux aller-retours suffisent dans la plupart des cas.)

Le protocole décrit dans ce RFC peut être utilisé pour divers services (cf. RFC 4252 et RFC 4254). Une des utilisations les plus fréquentes est celle de sessions interactives à distance, où SSH avait rapidement remplacé telnet. À l'époque, certaines personnes s'étaient inquiétées de l'augmentation de taille des paquets due à la cryptographie (nouveaux en-têtes, et MAC). Le débat est bien dépassé aujourd'hui mais une section 5.3 du RFC discute toujours la question. SSH ajoute au moins 28 octets à chaque paquet. Pour un transfert de fichiers, où les paquets ont la taille de la MTU, cette augmentation n'est pas importante. Pour les sessions interactives, où il n'y a souvent qu'un seul octet de données dans un paquet, c'est plus significatif, mais il faut aussi prendre en compte le reste des en-têtes. Ainsi, IP et TCP ajoutent déjà 32 octets au minimum (en IPv4). Donc l'augmentation due à SSH n'est pas de 2800 % mais de seulement 55 %. Et c'est sans même prendre en compte les en-têtes Ethernet. En parlant d'Ethernet, il faut aussi noter que la taille minimale d'une trame Ethernet est de 46 octets (cf. RFC 894), de toute façon et que donc, sans SSH, il faudrait de toute façon remplir la trame… Bref, le problème n'est guère important. (Le RFC donne un autre exemple, avec des modems lents, qui n'est probablement plus d'actualité aujourd'hui.)

La section 6 du RFC décrit ensuite le format des en-têtes SSH, un format binaire, comme le DNS ou BGP, mais pas comme SMTP ou HTTP version 1. Le tout est évidemment chiffré (même la longueur du paquet, qu'on ne peut donc pas connaitre avant de déchiffrer). Le chiffrement se fait avec l'algorithme sélectionné dans la phase de négociation. Si vous utilisez OpenSSH, l'option -v affichera l'algorithme, ici ChaCha20 :


% ssh -v $ADDRESS
...
debug1: kex: server->client cipher: chacha20-poly1305@openssh.com MAC: <implicit> compression: none
debug1: kex: client->server cipher: chacha20-poly1305@openssh.com MAC: <implicit> compression: none

  
ChaCha20 n'existait pas à l'époque du RFC 4253. Il n'est toujours pas enregistré à l'IANA. C'est ce qui explique que le nom d'algorithme inclut un arobase suivi d'un nom de domaine, c'est la marque des algorithmes locaux (ici, local à OpenSSH), non enregistrés officiellement. Un article du programmeur décrit l'intégration de ChaCha20 dans OpenSSH. Il y avait eu une tentative de normalisation (dans l'Internet-Draft draft-josefsson-ssh-chacha20-poly1305-openssh) mais elle a été abandonnée. C'était peut-être simplement par manque de temps et d'intérêt, car ChaCha20 est utilisé dans d'autres protocoles cryptographiques de l'IETF comme TLS (cf. RFC 7905 et, pour une vision plus générale, RFC 8439). OpenSSH permet d'afficher la liste des algorithmes de chiffrement symétriques qu'il connait avec l'option -Q cipher :
% ssh -Q cipher
3des-cbc
aes128-cbc
aes192-cbc
aes256-cbc
rijndael-cbc@lysator.liu.se
aes128-ctr
aes192-ctr
aes256-ctr
aes128-gcm@openssh.com
aes256-gcm@openssh.com
chacha20-poly1305@openssh.com
  
À l'inverse, le RFC 4253 listait des algorithmes qui ont été abandonnés depuis comme RC4 (nommé arcfour dans le RFC pour des raisons juridiques), retiré par le RFC 8758. La liste comprend également l'algorithme none (pas de chiffrement) qui avait été inclus pour des raisons douteuses de performance et dont l'usage est évidemment déconseillé (section 6.3 de notre RFC).

Le paquet inclut également un MAC pour assurer son intégrité. Il est calculé avant le chiffrement. Pour le MAC aussi, la liste des algorithmes a changé depuis la parution du RFC 4253. On peut afficher ceux qu'OpenSSH connait (les officiels sont dans un registre IANA) :

% ssh -Q mac        
hmac-sha1
hmac-sha1-96
hmac-sha2-256
hmac-sha2-512
hmac-md5
hmac-md5-96
umac-64@openssh.com
umac-128@openssh.com
hmac-sha1-etm@openssh.com
hmac-sha1-96-etm@openssh.com
hmac-sha2-256-etm@openssh.com
hmac-sha2-512-etm@openssh.com
hmac-md5-etm@openssh.com
hmac-md5-96-etm@openssh.com
umac-64-etm@openssh.com
umac-128-etm@openssh.com
  

Bon, mais les algorithmes de chiffrement symétrique comme ChaCha20 nécessitent une clé secrète et partagée entre les deux parties. Comment est-elle négociée ? Un algorithme comme par exemple Diffie-Hellman sert à choisir un secret, d'où sera dérivée la clé.

Le format binaire des messages est décrit en section 6 en utilisant des types définis dans le RFC 4251, section 5, comme byte[n] pour une suite d'octets ou uint32 pour un entier non signé sur 32 bits. Ainsi, un certificat ou une clé publique sera :

string    certificate or public key format identifier
byte[n]   key/certificate data
    
Un paquet SSH a la structure (après le point-virgule, un commentaire) :
uint32    packet_length
byte      padding_length
byte[n1]  payload; n1 = packet_length - padding_length - 1
byte[n2]  random padding; n2 = padding_length
byte[m]   mac (Message Authentication Code - MAC); m = mac_length    
  
La charge utile (payload) a un format qui dépend du type de messages. Par exemple, le message d'échange de clés initial, où chacun indique les algorithmes qu'il connait :
byte         SSH_MSG_KEXINIT
byte[16]     cookie (random bytes)
name-list    kex_algorithms
name-list    server_host_key_algorithms
name-list    encryption_algorithms_client_to_server
name-list    encryption_algorithms_server_to_client
name-list    mac_algorithms_client_to_server
name-list    mac_algorithms_server_to_client
name-list    compression_algorithms_client_to_server
name-list    compression_algorithms_server_to_client
name-list    languages_client_to_server
name-list    languages_server_to_client
boolean      first_kex_packet_follows
uint32       0 (reserved for future extension)
    

Les types de message (message ID ou message numbers) possibles sont listés dans un registre IANA. Par exemple l'exemple ci-dessus est un message de type SSH_MSG_KEXINIT, type qui est défini en section 12 et dans le RFC 4250, section 4.1.2. Il a la valeur 20.

Affiché par Wireshark, voici quelques messages que SSH transmet en clair, avant le début du chiffrement. Après l'échange des bannières, il y aura le KEXINIT en clair, Wireshark suit les termes du RFC donc vous pouvez facilement comparer ce message réel à la description abstraite du RFC, ci-dessus :

    
SSH Protocol
    SSH Version 2 (encryption:chacha20-poly1305@openssh.com mac:<implicit> compression:none)
        Packet Length: 1388
        Padding Length: 4
        Key Exchange
            Message Code: Key Exchange Init (20)
            Algorithms
                kex_algorithms length: 269
                kex_algorithms string [truncated]: curve25519-sha256,curve25519-sha256@libssh.org,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group16-sha512,diffie-hellman-group18-sha512,di
                server_host_key_algorithms length: 358
                server_host_key_algorithms string [truncated]: ecdsa-sha2-nistp256-cert-v01@openssh.com,ecdsa-sha2-nistp384-cert-v01@openssh.com,ecdsa-sha2-nistp521-cert-v01@openssh.com,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,ssh-ed25
                encryption_algorithms_client_to_server length: 108
                encryption_algorithms_client_to_server string: chacha20-poly1305@openssh.com,aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm@openssh.com,aes256-gcm@openssh.com
                encryption_algorithms_server_to_client length: 108
                encryption_algorithms_server_to_client string: chacha20-poly1305@openssh.com,aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm@openssh.com,aes256-gcm@openssh.com
                mac_algorithms_client_to_server length: 213
                mac_algorithms_client_to_server string [truncated]: umac-64-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-sha1-etm@openssh.com,umac-64@openssh.com,umac-128@openssh.com,hmac-sha2-
                mac_algorithms_server_to_client length: 213
                mac_algorithms_server_to_client string [truncated]: umac-64-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-sha1-etm@openssh.com,umac-64@openssh.com,umac-128@openssh.com,hmac-sha2-
                compression_algorithms_client_to_server length: 26
                compression_algorithms_client_to_server string: none,zlib@openssh.com,zlib
                compression_algorithms_server_to_client length: 26
                compression_algorithms_server_to_client string: none,zlib@openssh.com,zlib

  
Notez qu'un seul message SSH contient tous les algorithmes, aussi bien ceux servant à l'authentification qu'à l'échange de clés, ou qu'au chiffrement symétrique. Le premier algorithme listé est le préféré. Si les deux parties ont le même algorithme préféré, il est choisi. Autrement, on boucle sur les algorithmes listés par le client, dans l'ordre, en sélectionnant le premier qui est accepté par le serveur. Voici maintenant le lancement de l'échange de clés :

SSH Protocol
    SSH Version 2 (encryption:chacha20-poly1305@openssh.com mac:<implicit> compression:none)
        Packet Length: 44
        Padding Length: 6
        Key Exchange
            Message Code: Diffie-Hellman Key Exchange Init (30)
            Multi Precision Integer Length: 32
            DH client e: c834ef50c9ce27fa5ab43886aec2161a3692dd5e3267b567...
            Padding String: 000000000000

  
Et la réponse en face :
    
SSH Protocol
    SSH Version 2 (encryption:chacha20-poly1305@openssh.com mac:<implicit> compression:none)
        Packet Length: 260
        Padding Length: 9
        Key Exchange
            Message Code: Diffie-Hellman Key Exchange Reply (31)
            KEX host key (type: ecdsa-sha2-nistp256)
            Multi Precision Integer Length: 32
            DH server f: 2e34deb08146063fdba1d8800cf853a3a6830a3b8549ee5b...
            KEX H signature length: 101
            KEX H signature: 0000001365636473612d736861322d6e6973747032353600...
            Padding String: 000000000000000000
    SSH Version 2 (encryption:chacha20-poly1305@openssh.com mac:<implicit> compression:none)
        Packet Length: 12
        Padding Length: 10
        Key Exchange
            Message Code: New Keys (21)
            Padding String: 00000000000000000000

  
À partir de là, tout est chiffré et Wireshark ne peut plus afficher que du binaire sans le comprendre :
    
SSH Protocol
    SSH Version 2 (encryption:chacha20-poly1305@openssh.com mac:<implicit> compression:none)
        Packet Length (encrypted): 44cdc717
        Encrypted Packet: ea98dbf6cc50af65ba4186bdb5bf02aa9e8366aaa4c1153f
        MAC: e7a6a5a222fcdba71e834f3bb76c2282

  

OpenSSH avec son option -v permet d'afficher cette négociation :

    
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: algorithm: curve25519-sha256
debug1: kex: host key algorithm: ecdsa-sha2-nistp256
debug1: kex: server->client cipher: chacha20-poly1305@openssh.com MAC: <implicit> compression: none
debug1: kex: client->server cipher: chacha20-poly1305@openssh.com MAC: <implicit> compression: none

  
Et les algorithmes acceptés pour l'échange de clés :
% ssh -Q kex
diffie-hellman-group1-sha1
diffie-hellman-group14-sha1
diffie-hellman-group14-sha256
diffie-hellman-group16-sha512
diffie-hellman-group18-sha512
diffie-hellman-group-exchange-sha1
diffie-hellman-group-exchange-sha256
ecdh-sha2-nistp256
ecdh-sha2-nistp384
ecdh-sha2-nistp521
curve25519-sha256
curve25519-sha256@libssh.org
  
(Ceux à courbes elliptiques comme curve25519-sha256 n'existaient pas à l'époque. curve25519-sha256 a été ajouté dans le RFC 8731.) On trouve aussi les algorithmes acceptés pour l'authentification du serveur via sa clé publique :
% ssh -Q key    
ssh-ed25519
ssh-ed25519-cert-v01@openssh.com
ssh-rsa
ssh-dss
ecdsa-sha2-nistp256
ecdsa-sha2-nistp384
ecdsa-sha2-nistp521
ssh-rsa-cert-v01@openssh.com
ssh-dss-cert-v01@openssh.com
ecdsa-sha2-nistp256-cert-v01@openssh.com
ecdsa-sha2-nistp384-cert-v01@openssh.com
ecdsa-sha2-nistp521-cert-v01@openssh.com
  

Ce RFC 4253 ne décrit que la couche basse de SSH. Au-dessus se trouvent plusieurs services qui tirent profit de la sécurité fournie par cette couche basse. Une fois la session chiffrée établie, le protocole SSH permet de lancer d'autres services. Ils ne sont que deux depuis le début, mais d'autres pourront se rajouter dans le registre IANA. Actuellement, il y a ssh-userauth (authentifier l'utilisateur, par mot de passe ou par clé publique, RFC 4252) et ssh-connection (connexion à distance, et services qui en dépendent, cf. RFC 4254).

Nous avons vu plus haut le type de messages SSH_MSG_KEXINIT (code numérique 20). Il y a de nombreux autres types, présentés dans la section 11 du RFC. Par exemple SSH_MSG_DISCONNECT (type 1 dans le registre IANA) est défini ainsi :

byte      SSH_MSG_DISCONNECT
uint32    reason code
string    description in ISO-10646 UTF-8 encoding [RFC3629]
string    language tag [RFC3066]
  
Il indique la fin de la session SSH (l'étiquette de langue pour indiquer la raison est désormais normalisée dans le RFC 5646, et plus le RFC 3066). Autre exemple, SSH_MSG_IGNORE (code 2) pour faire du remplissage afin de diminuer les risques d'analyse du trafic. Pour une vision complète des risques de sécurité de SSH, (re)lisez la très détaillée section 9 du RFC 4251.

Notez qu'il avait existé une version 1 du protocole SSH, qui n'a pas fait l'objet d'une normalisation formelle. La section 5 de notre RFC traite de la compatibilité entre la version actuelle, la 2, et cette vieille version 1, aujourd'hui complètement abandonnée. Ça, c'est le passé. Et le futur ? Le cœur de SSH n'a pas bougé depuis les RFC de la série du RFC 4250 au RFC 4254. Mais il existe un projet (pour l'instant individuel, non accepté par l'IETF de remplacer ce RFC 4253 par QUIC, en faisant tourner le reste de SSH sur QUIC (lisez draft-bider-ssh-quic).

  • August 2nd 2020 at 02:00

Python – Limiting user input to a number range

By italchemy

While writing a code, I came across a problem today. I wanted to control what the user response is in my application. For example, I only expect a positive integer from a specific range. For example, 1 to 99.

Source code 1:

limit_input0

number = None
while type(number) is not int:
try:
number = input(“Please enter a number: “)
number = int(number)
print(“You entered: %d” % number)
except ValueError:
print(“%s is not an integer.\n” % number)

 

Result of code 1: Does not take non-integers but takes 0 or minus integers too.

Please enter a number: abcd
abcd is not an integer.

Please enter a number: -99
You entered: -99
Enter the number of students (between 1 and 99) : -99
You have answered, there are -99 student(s).

 

Source code 2:

limit_input1

no_students = None
while type(no_students) is not int or no_students <= 0 or no_students >= 100:
try:
no_students = input(r”Enter the number of students (between 1 and 99) : “)
no_students = int(no_students)
print(“You have answered, there are %d student(s).” % no_students)
except ValueError:
print(“%s is not an integer.\n” % no_students)

  • note, “except ValueError” will stop working with this code.

Result of code 2: Does not take non-integers, 0, minus integer or bigger than 100. Only excepst an integer between 1 and 99.

Enter the number of students (between 1 and 99) : 1.5
1.5 is not an integer.

Enter the number of students (between 1 and 99) : abcd
abcd is not an integer.

Enter the number of students (between 1 and 99) : 0
You have answered, there are 0 student(s).
Enter the number of students (between 1 and 99) : 200
You have answered, there are 200 student(s).
Enter the number of students (between 1 and 99) : 45
You have answered, there are 45 student(s).

 

 

Source code 3:

limit_input2

no_devices = None
while type(no_devices) is not int or no_devices <= 0 or no_devices >= 5:
try:
no_devices = input(r”Enter the number of devices (between 1 and 99) : “)
no_devices = int(no_devices)
print(“You have answered, there are %d devices(s).” % no_devices)

except ValueError:
print(“%s is not an integer.\n” % no_devices)

  • note, “except ValueError” will stop working with this code.

Result of code 2: Does not take non-integers, 0, minus integer or bigger than 4. Only excepst an integer between 1 and 4.

Enter the number of devices (between 1 and 99) : 1.5
1.5 is not an integer.

Enter the number of devices (between 1 and 99) : abcd
abcd is not an integer.

Enter the number of devices (between 1 and 99) : 0
You have answered, there are 0 devices(s).
Enter the number of devices (between 1 and 99) : -99
You have answered, there are -99 devices(s).
Enter the number of devices (between 1 and 99) : 99
You have answered, there are 99 devices(s).
Enter the number of devices (between 1 and 99) : 3
You have answered, there are 3 devices(s).

 

 

 

RFC 8801: Discovering Provisioning Domain Names and Data

By Stéphane Bortzmeyer

Vous vous demandez certainement, chère lectrice et cher lecteur, ce qu'est un PvD (ProVisioning Domain). Cette notion n'est pas nouvelle, mais elle n'avait été formalisée rigoureusement qu'avec le RFC 7556. Un PvD est un domaine de l'Internet où des règles cohérentes de configuration du réseau s'appliquent. Au sein, d'un PvD, il y a un résolveur DNS à utiliser, des adresses IP spécifiques, des règles de routage et de sécurité que n'ont pas forcément les autres PvD. Ce nouveau RFC décrit une option IPv6 qui permet au PvD de signaler explicitement son existence, via un RA (Router Advertisement.)

La notion de PvD (ProVisioning Domain) est utile pour les machines qui ont plusieurs connexions, à des réseaux (et donc peut-être des PvD) différents, par exemple un ordinateur connecté à la fois à un FAI grand public et au VPN de l'entreprise. Il y a des PvD implicites : une machine qui connait le concept de PvD affecte un PvD implicite à chaque réseau et, par défaut, ne considère pas que le résolveur DNS de l'un convient pour les autres. Et il y a des PvD explicites, et c'est à eux qu'est consacré ce RFC. Un PvD explicite a un identificateur, qui a la syntaxe d'un FQDN. Attention, même si l'identificateur est un nom de domaine, le terme de « domaine » (le D de PvD) ne doit pas être confondu avec le sens qu'il a dans le DNS. L'intérêt d'un PvD explicite est qu'il permet d'avoir plusieurs domaines distincts sur la même interface réseau, et qu'on peut y associer des informations supplémentaires, récupérées sur le réseau ou bien préconfigurées.

On l'a vu, le concept de PvD avait été décrit dans le RFC 7556. Ce que notre nouveau RFC 8801 rajoute, c'est :

  • Une option aux RA (Router Advertisement, RFC 4861) pour indiquer aux machines IPv6 du réseau le PvD explicite,
  • Un mécanisme pour récupérer, en HTTPS, de l'information de configuration du réseau, pour les cas où cette information ne tiendrait pas dans le message RA. Elle est évidemment codée en JSON.
Le RA va donc indiquer le ou les identificateurs du ou des PvD du réseau. Notez qu'on peut avoir aussi le même PvD sur plusieurs réseaux, par exemple le Wi-Fi et le filaire chez moi font partie du même PvD et ont les mêmes règles et la même configuration.

Dans un monde idéal, l'utilisatrice dont l'ordiphone a à la fois une connexion 4G, une connexion Wi-Fi et un VPN par dessus, aurait un PvD pour chacun de ces trois réseaux différentes, et pourrait donc décider intelligemment quelle interface utiliser pour quel type de trafic. Par exemple, une requête DNS pour wiki.private.example.com (le wiki interne de l'entreprise) sera envoyée uniquement via le VPN, puisque les résolveurs des réseaux publics ne connaissent pas ce domaine. Autre exemple, l'information envoyée pour chaque PvD pourrait permettre aux applications de faire passer le trafic important (la vidéo en haute définition, par exemple), uniquement sur le réseau à tarification forfaitaire.

Bon, assez de considérations sur les PvD, passons aux nouvelles normes décrites dans ce RFC. D'abord, l'option RA. Elle est décrite dans la section 3. C'est très simple : une nouvelle option RA est créée, la 21, « PvD ID Router Advertisement Option », suivant le format classique des options RA, TLV (Type-Longueur-Valeur). Elle contient, entre autres :

  • Un bit nommé H qui indique que le client peut récupérer des informations supplémentaires en HTTP (c'est détaillé en section 4 du RFC),
  • Un bit nommé L qui indique que ce PvD est également valable pour IPv4,
  • Un bit nommé R qui indique que le RA contient un autre RA (détails en section 5),
  • Et bien sûr l'identificateur (PvD ID) lui-même, sous la forme d'un FQDN.
Si jamais il y a plusieurs PvD sur le réseau, le routeur doit envoyer des RA différents, il n'est pas autorisé à mettre plusieurs options PvD dans un même RA.

Que va faire la machine qui reçoit une telle option dans un RA ? Elle doit marquer toutes les informations de configuration qui étaient dans le RA comme étant spécifiques à ce PvD. Par exemple, si la machine a deux interfaces, et reçoit un RA sur chacune, ayant des PvD différents, et donnant chacun l'adresses d'un résolveur DNS (RFC 8106), alors ce résolveur ne doit être utilisé que pour le réseau où il a été annoncé (et avec une adresse IP source de ce réseau). Rappelez-vous que différents résolveurs DNS peuvent donner des résultats différents, par exemple un des réseaux peut avoir un Pi-hole qui donne des réponses mensongères, afin de bloquer la publicité. (En parlant du DNS, des détails sur cette question complexe figurent dans la section 5.2.1 du RFC 7556.) Autre exemple, si on utilise un VPN vers son employeur, les requêtes DNS pour les ressources internes (congés.rh.example.com…) doivent être envoyées au résolveur de l'employeur, un résolveur extérieur peut ne pas être capable de les résoudre. En fait, tous les cas où la réponse DNS n'est pas valable publiquement nécessitent d'utiliser le bon résolveur DNS. C'est aussi ce qui se passe avec NAT64 (RFC 6147).

Idem pour d'autres informations de configuration comme le routeur par défaut : elles doivent être associées au PvD. Une machine qui connait les PvD ne peut donc pas se contenter d'une table simple listant le résolveur DNS, le routeur par défaut, etc. Elle doit avoir une table par PvD.

Si la machine récupère par ailleurs des informations de configuration avec DHCP, elle doit également les associer à un PvD, par exemple en utilisant comme PvD implicite celui de l'interface réseau utilisée.

Et pour IPv4, si le bit L est à un ? Dans ce cas, l'information IPv4 reçue sur la même interface doit être associée à ce PvD. (Notez que si plusieurs PvD sur la même interface ont le bit L, on ne peut rien décider, à part que quelqu'un s'est trompé.)

Les machines qui partagent leur connexion (tethering), ce qui est fréquent pour les connexions mobiles comme la 4G (RFC 7278), doivent relayer le RA contenant l'option PvD vers le réseau avec qui elles partagent (comme elles relaient d'autres messages similaires, cf. RFC 4389). Cela permettra à des techniques qui facilitent le partage, comme la délégation de préfixe du RFC 8415, de bien fonctionner. Même si la machine partageuse ne reçoit pas d'option PvD, il est recommandé qu'elle en ajoute une pour le bénéfice des engins avec qui elle partage sa connectivité.

Tout cela, c'était pour une machine PvD-aware, une machine qui sait ce qu'est un PvD et qui sait le gérer. Mais avec du vieux logiciel, écrit avant le concept de PvD, que se passe-t-il ? Une machine munie de ce logiciel va évidemment ignorer l'option PvD du RA et donc utiliser un seul résolveur DNS, un seul routeur par défaut pour tous les cas. Elle aura sans doute beaucoup de problèmes si plusieurs interfaces réseau sont actives et, en pratique, il vaudra mieux n'avoir qu'une seule interface à un moment donné.

Nous avons vu plus haut que, si le bit H dans l'option PvD est à 1, la machine peut obtenir davantage d'informations (PvD Additional Information) en HTTP. Cette information sera encodée en I-JSON (RFC 7493.) Pourquoi ne pas avoir mis ces informations dans le RA ? Parce qu'elles sont trop grosses ou, tout simplement, pas critiques, et pouvant être ignorées. Et on les récupère où, ces informations ? Si le PvD est radio.example.com, l'URL à utiliser est https://radio.example.com/.well-known/pvd (préfixe .well-known désormais enregistré.) Attention, on ne doit tenter d'accéder à cet URL que si le bit H était à 1. C'est du HTTPS (RFC 2818) et il faut donc vérifier le certificat (cf. RFC 6125.) Vous voyez qu'on ne peut pas choisir un PvD au hasard : il faut qu'il soit un nom de domaine qu'on contrôle, et pour lequel on peut obtenir un certificat. Si on configure un des ces affreux portails captifs, il faut s'assurer que les clients auront le droit de se connecter au serveur HTTP indiqué.

Les données auront le type application/pvd+json. Elles contiennent obligatoirement :

  • Le PvD,
  • une date d'expiration, au format RFC 3339,
  • les préfixes IP du PvD.
Ainsi que, si on veut :
  • les domaines où chercher les noms qui ne sont pas des FQDN,
  • une indication que ce PvD n'a pas de connexion à l'Internet.
D'autres membres peuvent être présents, un registre IANA existe et, pour y ajouter des termes, c'est la procédure « Examen par un expert » du RFC 8126.

Voici un exemple, avec le PvD smart.mpvd.io (qui a servi à un hackathon IETF) :

% curl  https://smart.mpvd.io/.well-known/pvd 
{
	"name": "PvD for smart people",
	"prefixes": ["2001:67c:1230:101::/64", "2001:67c:1230:111::/64"],
	"noInternet": false,
	"metered": false,
	"captivePortalURL" : "https://smart.mpvd.io/captive.php"
}
  
On notera que le membre expires manque, ce qui n'est pas bien, et que le membre identifier, qui devrait indiquer le PvD, est également absent, ce qui est encore plus mal. On voit qu'il s'agissait d'une expérimentation. Voici ce qu'aurait dû être l'objet JSON :
{
        "identifier": "smart.mpvd.io",
        "expires": "2020-04-08T15:30:00Z",
	"prefixes": ["2001:67c:1230:101::/64", "2001:67c:1230:111::/64"],
	"noInternet": false,
	"name": "PvD for smart people",
	"metered": false,
	"captivePortalURL" : "https://smart.mpvd.io/captive.php"
}
  
Si vous connaissez d'autres serveurs d'information PvD, indiquez-les moi. Mais il est probable que la plupart ne seront accessibles que depuis un réseau interne.

Voilà, vous savez l'essentiel désormais. La section 5 du RFC ajoute quelques considérations pratiques. D'abord, le bit R qui permettait à une option PvD d'inclure un RA. À quoi ça sert ? L'idée est que, pendant longtemps, la plupart des réseaux accueilleront un mélange de machines qui connaissent les PvD, et de machines qui ne sont pas conscientes de ce concept. Le bit R sert à envoyer des informations qui ne seront comprises que des premières. Par exemple, on met un préfixe dans le RA et, dans l'option PvD, un autre RA qui contient un autre préfixe. Les machines qui connaissent les PvD verront et utiliseront les deux préfixes, celles qui ne connaissent pas les PvD ignoreront l'option et n'auront que le premier préfixe. On peut également envoyer deux RA, un ne contenant pas d'option PvD, et un en contenant une (plus le « vrai » RA).

Un peu de sécurité, pour finir (section 6). D'abord, il faut bien se rappeler que les RA, envoyés en clair et non authentifiés, n'offrent aucune sécurité. Il est trivial, pour un méchant connecté au réseau, d'envoyer de faux RA et donc de fausses options PvD. En théorie, des protocoles comme IPsec ou SEND (RFC 3971) peuvent sécuriser les RA mais, en pratique, on ne peut guère compter dessus. Les seules solutions de sécurisation effectivement déployées sont au niveau 2, par exemple 802.1X combiné avec le RFC 6105. Ce n'est pas un problème spécifique à l'option PvD, c'est la sécurité (ou plutôt l'insécurité) des RA.

Ah, et un petit mot sur la vie privée (section 7 du RFC). La connexion au serveur HTTP va évidemment laisser des traces, et il est donc recommandé de la faire depuis une adresse source temporaire (RFC 4941), et sans envoyer User-Agent: ou cookies.

Question mise en œuvre, il y a eu du code libre pour des tests (incluant une modification du noyau Linux, et un dissecteur pour Wireshark) mais je ne sais pas ce que c'est devenu et où en sont les systèmes d'exploitation actuels.

  • July 29th 2020 at 02:00

RFC 8744: Issues and Requirements for Server Name Identification (SNI) Encryption in TLS

By Stéphane Bortzmeyer

Le but du protocole de cryptographie TLS est de protéger une session contre l'écoute par un indiscret, et contre une modification par un tiers non autorisé. Pour cela, TLS chiffre toute la session. Toute la session ? Non, certaines informations circulent en clair, car elles sont nécessaires pour la négociation des paramètres de chiffrement. Par exemple, le SNI (Server Name Indication) donne le nom du serveur qu'on veut contacter. Il est nécessaire de le donner en clair car la façon dont vont se faire le chiffrement et l'authentification dépendent de ce nom. Mais cela ouvre des possibilités aux surveillants (savoir quel serveur on contacte, parmi tous ceux qui écoutent sur la même adresse IP) et aux censeurs (couper sélectivement les connexions vers certains serveurs). Il est donc nécessaire de protéger ce SNI, ce qui n'est pas facile. Ce nouveau RFC décrit les objectifs, mais pas encore la solution. Celle-ci reposera sans doute sur la séparation entre un frontal général qui acceptera les connexions TLS, et le « vrai » service caché derrière.

C'est que le problème est difficile puisqu'on est face à un dilemme de l'œuf et de la poule. On a besoin du SNI pour chiffrer alors qu'on voudrait chiffrer le SNI. Le RFC note qu'il n'y aura sans doute pas de solution parfaite.

Cela fait longtemps que le SNI (normalisé il y a longtemps, dans le RFC 3546, et aujourd'hui dans le RFC 6066) est connu pour les risques qu'il pose pour la vie privée. Les autres canaux de fuite d'information sont fermés petit à petit (par exemple le DNS, avec les RFC 7816, RFC 7858 et RFC 8484), souvent en utilisant TLS (RFC 8446). Même l'adresse IP de destination, qu'on ne peut pas cacher, perd de sa signification lorsque de nombreux services sont hébergés derrière la même adresse IP (c'est particulièrement vrai pour les gros CDN). Mais ces services comptent sur le SNI (Server Name Indication), transporté en clair dans le message TLS ClientHello, pour le démultiplexage des requêtes entrantes, et ce SNI tend donc à devenir le maillon faible de la vie privée, l'information la plus significative qui reste en clair. Voici, vu par tshark, un exemple de ClientHello, avec un SNI (server_name, affiche tshark) :

...
Secure Sockets Layer
TLSv1 Record Layer: Handshake Protocol: Client Hello
    Content Type: Handshake (22)
    Version: TLS 1.0 (0x0301)
    Length: 233
    Handshake Protocol: Client Hello
        Handshake Type: Client Hello (1)
            Length: 229
            Version: TLS 1.2 (0x0303)
...
            Extension: server_name (len=22)
                Type: server_name (0)
                Length: 22
                Server Name Indication extension
                    Server Name list length: 20
                    Server Name Type: host_name (0)
                    Server Name length: 17
                    Server Name: doh.bortzmeyer.fr
  
Résultat, le SNI est souvent utilisé de manière intrusive, le RFC 8404 donnant de nombreux exemples. Par exemple, il permet de censurer finement (si le SNI indique site-interdit.example, on jette les paquets, s'il indique site-commercial.example, on laisse passer). Il permet de shaper le trafic vers certains sites, en violation de la neutralité du réseau. Il permet aussi de laisser passer certains sites, lorsqu'on fait une attaque de l'homme du milieu, par exemple une entreprise qui fait de l'inspection HTTPS systématique peut utiliser le SNI pour en exempter certaines sites sensibles, comme ceux des banques ou des plate-formes médicales. Et, bien sûr, le SNI peut être passivement observé à des fins de surveillance (RFC 7258).

On peut s'amuser à noter que ces risques pour la vie privée n'avaient pas été notés dans la section « Sécurité » des RFC de normalisation de SNI, comme le RFC 6066. C'est peut-être parce qu'à l'époque, les éventuels attaquants avaient des moyens plus simples à leur disposition. (Je me souviens de discussions à l'IETF « à quoi bon masquer le SNI puisque le DNS révèle tout ? » ; c'était avant le RFC 7626.) Il restait un endroit où le nom du service était en clair, c'était le certificat renvoyé par le serveur TLS (subjectAltName) mais, depuis TLS 1.3 (RFC 8446), lui aussi est chiffré. Aujourd'hui, les progrès de la sécurité font que le moyen le plus simple de savoir à quel service un internaute se connecte devient souvent le SNI.

Notez toutefois que tout le monde n'est pas d'accord sur la nécessité de chiffrer le SNI. Certains craignent que cette nécessité débouche sur une solution compliquée et fragile. D'autres ne veulent tout simplement pas priver surveillants et censeurs d'un mécanisme si pratique. En réponse à cette dernière objection (cf. RFC 8404), le RFC note que la méthode recommandée (section 2.3 du RFC), si on peut surveiller et filtrer, est de le faire dans les machines terminales. Après tout, si l'organisation contrôle ces machines terminales, elle peut les configurer (par exemple avec le certificat de l'intercepteur) et si elle ne les contrôle pas, elle n'a sans doute pas le droit d'intercepter les communications.

La solution est évidente, chiffrer le SNI. Ce ne sont pas les propositions qui ont manqué, depuis des années. Mais toutes avaient des inconvénients sérieux, liés en général à la difficulté du bootstrap. Avec quelle clé le chiffrer puisque c'est justement le SNI qui aide le serveur à choisir la bonne clé ?

La section 3 de notre RFC énumère les exigences auxquelles va devoir répondre la solution qui sera adoptée. (Rappelez-vous qu'il s'agit d'un travail en cours.) C'est que beaucoup de solutions ont déjà été proposées, mais toutes avaient de sérieux problèmes. Petit exercice avant de lire la suite : essayez de concevoir un protocole de chiffrement du SNI (par exemple « le SNI est chiffré avec la clé publique du serveur, récupérée via DANE » ou bien « le SNI est chiffré par une clé symétrique qui est le condensat du nom du serveur [vous pouvez ajouter du sel si vous voulez, mais n'oubliez pas d'indiquer où le trouver] ») et voyez ensuite si cette solution répond aux exigences suivantes.

Par exemple, pensez à la possibilité d'attaque par rejeu. Si le SNI est juste chiffré avec une clé publique du serveur, l'attaquant n'a qu'à observer l'échange, puis faire à son tour une connexion au serveur en rejouant le SNI chiffré et paf, dans la réponse du serveur, l'attaquant découvrira quel avait été le service utilisé. La solution choisie doit empêcher cela.

Évidemment, la solution ne doit pas imposer d'utiliser un secret partagé (entre le serveur et tous ses clients), un tel secret ne resterait pas caché longtemps.

Il faut aussi faire attention au risque d'attaque par déni de service, avec un méchant qui générerait plein de SNI soi-disant chiffrés pour forcer des déchiffrements inutiles. Certes, TLS permet déjà ce genre d'attaques mais le SNI peut être traité par une machine frontale n'ayant pas forcément les mêmes ressources que le vrai serveur.

Autre chose importante quand on parle de protéger la vie privée : il ne faut pas se distinguer (Do not stick out). Porter un masque du Joker dans la rue pour protéger son anonymat serait sans doute une mauvaise idée, risquant au contraire d'attirer l'attention. La solution choisie ne doit donc pas permettre à, par exemple, un état policier, de repérer facilement les gens qui sont soucieux de leur vie privée. Une extension spécifique du ClientHello serait dangereuse, car triviale à analyser automatiquement par un système de surveillance massive.

Il est évidemment souhaitable d'avoir une confidentialité persistante, c'est-à-dire que la compromission d'une clé privée ne doit pas permettre de découvrir, a posteriori, les serveurs auxquels le client s'était connecté. Simplement chiffrer le SNI avec la clé publique du serveur ne convient donc pas.

L'hébergement Web d'aujourd'hui est souvent compliqué, on peut avoir un frontal géré par une société d'hébergement, et des machines gérées par le client de l'hébergeur derrière, par exemple. Ou bien plusieurs clients de l'hébergeur sur la même machine physique, voire sur la même machine virtuelle avec certaines hébergements mutualisés. Cela peut être utile pour certaines solutions, par exemple le fronting où une machine frontale reçoit une demande de connexion TLS pour elle puis, une fois TLS démarré, reçoit le nom du vrai serveur, et relaie vers lui. Si la machine frontale relaie pour beaucoup de serveurs, cela fournit une assez bonne intimité. Mais cela nécessite de faire confiance à la machine frontale, et le risque d'attaque de l'homme du milieu (qui nous dit que ce frontal est le frontal légitime choisi par le serveur TLS ?) augmente. Or, plus la machine frontale protège des serveurs, plus elle est un objectif tentant pour la police ou les pirates.

Ah, et j'ai parlé du Web mais la solution doit évidemment fonctionner avec d'autres protocoles que HTTPS. Par exemple, le DNS sur TLS du RFC 7858 ou bien IMAP (RFC 8314) doivent fonctionner. Même pour HTTP, certaines particularités de HTTP peuvent poser problème, et il est donc important que la future solution de chiffrement de SNI soit agnostique, pour marcher avec tous les protocoles. Et elle doit également fonctionner avec tous les protocoles de transport, pas seulement TCP, mais aussi DTLS ou QUIC.

Le RFC note aussi qu'il serait bon d'avoir une solution de chiffrement de la négociation ALPN (RFC 7301). ALPN est moins indiscret que SNI mais il renseigne sur l'application utilisée.

Puisque j'ai parlé plus haut du fronting, cela vaut la peine de parler du fronting HTTP car c'est une technique courante, aussi bien pour échapper à la censure que pour protéger la vie privée. La section 4 du RFC lui est consacrée. Elle est décrite dans l'article de Fifield, D., Lan, C., Hynes, R., Wegmann, P., et V. Paxson, « Blocking-resistant communication through domain fronting ». Le principe est que le client TLS établit une connexion avec le système de fronting puis, une fois le chiffrement TLS en marche, le client demande la connexion avec le vrai serveur. Un surveillant ne pourra voir que l'utilisation d'un service de fronting, pas le nom du vrai service (le SNI en clair dira, par exemple, fronting.example.net). En pratique, cela marche bien avec HTTPS si le serveur de fronting et le vrai serveur sont sur le même système : il suffit alors d'indiquer le domaine du fronting dans le SNI et le vrai domaine dans les en-têtes Host: de HTTP. Cela ne nécessite aucune modification du protocole TLS.

Le fronting a quelques limites :

  • Le client doit trouver un service acceptant de faire du fronting. (Ce qui n'est pas évident.)
  • Le client doit configurer son logiciel pour utiliser un service de fronting.
  • Il faut évidemment faire confiance au service de fronting, qui est, d'une certaine façon, un homme du milieu. (Ceci dit, si serveur de fronting et vrai serveur sont au même endroit, cela n'implique pas de faire confiance à un nouvel acteur.) Le problème est d'autant plus crucial qu'il n'existe pas de moyen standard, pour un serveur, d'authentifier publiquement le service de fronting par lequel on peut y accéder. Des variantes du fronting existent, qui limitent ce problème, par exemple en faisant du HTTPS dans HTTPS, si le serveur de fronting l'accepte.
  • Cela ne marche qu'avec HTTP, puisque cela utilise le fait que les requêtes HTTP indiquent le vrai serveur de destination. (C'est d'ailleurs une des raisons pour lesquelles a été développé DoH, spécifié dans le RFC 8484.)
À noter que les trames ORIGIN du RFC 8336 peuvent être utiles en cas de fronting, pour indiquer le contenu venant du « vrai » serveur.

Voilà, vous connaissez maintenant le problème, l'IETF est en train de travailler aux solutions, le brouillon le plus avancé est draft-ietf-tls-esni.

  • July 29th 2020 at 02:00

Python – Limiting user input to a number range

By italchemy

While writing a code, I came across a problem today. I wanted to control what the user response is in my application. For example, I only expect a positive integer from a specific range. For example, 1 to 99.

Source code 1:

limit_input0

number = None
while type(number) is not int:
try:
number = input(“Please enter a number: “)
number = int(number)
print(“You entered: %d” % number)
except ValueError:
print(“%s is not an integer.\n” % number)

 

Result of code 1: Does not take non-integers but takes 0 or minus integers too.

Please enter a number: abcd
abcd is not an integer.

Please enter a number: -99
You entered: -99
Enter the number of students (between 1 and 99) : -99
You have answered, there are -99 student(s).

 

Source code 2:

limit_input1

no_students = None
while type(no_students) is not int or no_students <= 0 or no_students >= 100:
try:
no_students = input(r”Enter the number of students (between 1 and 99) : “)
no_students = int(no_students)
print(“You have answered, there are %d student(s).” % no_students)
except ValueError:
print(“%s is not an integer.\n” % no_students)

  • note, “except ValueError” will stop working with this code.

Result of code 2: Does not take non-integers, 0, minus integer or bigger than 100. Only excepst an integer between 1 and 99.

Enter the number of students (between 1 and 99) : 1.5
1.5 is not an integer.

Enter the number of students (between 1 and 99) : abcd
abcd is not an integer.

Enter the number of students (between 1 and 99) : 0
You have answered, there are 0 student(s).
Enter the number of students (between 1 and 99) : 200
You have answered, there are 200 student(s).
Enter the number of students (between 1 and 99) : 45
You have answered, there are 45 student(s).

 

 

Source code 3:

limit_input2

no_devices = None
while type(no_devices) is not int or no_devices <= 0 or no_devices >= 5:
try:
no_devices = input(r”Enter the number of devices (between 1 and 99) : “)
no_devices = int(no_devices)
print(“You have answered, there are %d devices(s).” % no_devices)

except ValueError:
print(“%s is not an integer.\n” % no_devices)

  • note, “except ValueError” will stop working with this code.

Result of code 2: Does not take non-integers, 0, minus integer or bigger than 4. Only excepst an integer between 1 and 4.

Enter the number of devices (between 1 and 99) : 1.5
1.5 is not an integer.

Enter the number of devices (between 1 and 99) : abcd
abcd is not an integer.

Enter the number of devices (between 1 and 99) : 0
You have answered, there are 0 devices(s).
Enter the number of devices (between 1 and 99) : -99
You have answered, there are -99 devices(s).
Enter the number of devices (between 1 and 99) : 99
You have answered, there are 99 devices(s).
Enter the number of devices (between 1 and 99) : 3
You have answered, there are 3 devices(s).

 

 

 

Cisco 3750/3850 install IOS using archive tar method

By italchemy

I have been working on Cisco 3850 and it has a new installation method called INSTALL mode which unpacks all files and save time during the book up and processing time. Since I do not have a Cisco 3850, the closest thing I can emulate this is the tar method used on older 3750 switches. My switches were running on BUNDLE mode, so had to archive tar the file to install the IOS on its seperate directory.

INSTALL method – decompress all files to the flash, similar to old tar method

BUNDLE mode – if you simply dump the IOS on the root of the flash:/ and your device is booting up from undecompressed image (.bin) file.

 

Read about 3850 INSTALL vs BUNDLE IOS upgrade and recovery process.

https://www.cisco.com/c/en/us/support/docs/switches/catalyst-3850-series-switches/117552-technote-cat3850-00.html

========

Important Command used:

show switch

switch 1 renumber 2

show flash

archive tar /xtract tftp://192.168.254.10/c3750-ipbasek9-tar.122-55.SE1.tar flash:

========

 
Switch#show switch
Switch/Stack Mac Address : 0023.059d.de00
H/W Current
Switch# Role Mac Address Priority Version State
———————————————————-
*1 Master 0023.059d.de00 10 0 Ready

Switch#conf t
Switch(config)#no switch 1 priority 14
Changing the Switch Priority of Switch Number 1 to 1
Do you want to continue?[confirm]
New Priority has been set successfully
Switch(config)#switch 1 renumber 2
WARNING: Changing the switch number may result in a
configuration change for that switch.
The interface configuration associated with the old switch
number will remain as a provisioned configuration.
Do you want to continue?[confirm]
Changing Switch Number 1 to Switch Number 2
New Switch Number will be effective after next reboot
Switch#ping 192.168.254.10
Sending 5, 100-byte ICMP Echos to 192.168.254.10, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/203/1007 ms

Switch#show flash

Directory of flash:/

2 -rwx 13006601 Mar 1 1993 03:44:48 +00:00 c3750-ipservicesk9-mz.122-55.SE5.bin
3 -rwx 676 Mar 1 1993 00:03:56 +00:00 vlan.dat
4 -rwx 1048 Mar 1 1993 00:01:44 +00:00 multiple-fs

15998976 bytes total (2988544 bytes free)
Switch#delete flash:c3750-ipservicesk9-mz.122-55.SE5.bin
Delete filename [c3750-ipservicesk9-mz.122-55.SE5.bin]?
Delete flash:c3750-ipservicesk9-mz.122-55.SE5.bin? [confirm]
Switch#$archive tar /xtract tftp://192.168.254.10/c3750-ipbasek9-tar.122-55.SE1.tar flash:
Loading c3750-ipbasek9-tar.122-55.SE1.tar from 192.168.254.10 (via Vlan1): !
c3750-ipbasek9-mz.122-55.SE1/ (directory)
c3750-ipbasek9-mz.122-55.SE1/html/ (directory)
extracting c3750-ipbasek9-mz.122-55.SE1/html/layers.js (1616 bytes)
extracting c3750-ipbasek9-mz.122-55.SE1/html/title.js (577 bytes)
… [Ommitted for brevity]
extracting c3750-ipbasek9-mz.122-55.SE1/html/images/cna_icon4.gif (1072 bytes)
extracting c3750-ipbasek9-mz.122-55.SE1/html/images/205701.gif (17278 bytes)
extracting c3750-ipbasek9-mz.122-55.SE1/c3750-ipbasek9-mz.122-55.SE1.bin (12079771 bytes)!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!OOOOOOOOOOOOOOO!OOOOOOOOOOOOOOOOOOOO!OOOOOOOOOOOOOOOOOOOO!OOOOOOOOOOO
extracting c3750-ipbasek9-mz.122-55.SE1/info (681 bytes)O
extracting info (106 bytes)
[OK – 15257600 bytes]

Switch#show flash

Directory of flash:/

2 drwx 192 Mar 1 1993 00:17:41 +00:00 c3750-ipbasek9-mz.122-55.SE1
3 -rwx 676 Mar 1 1993 00:03:56 +00:00 vlan.dat
4 -rwx 1048 Mar 1 1993 00:01:44 +00:00 multiple-fs
449 -rwx 106 Mar 1 1993 00:17:42 +00:00 info

15998976 bytes total (948224 bytes free)

 
Switch#show boot system
flash:c3750-ipservicesk9-mz.122-55.SE5.bin

Switch#conf t

Switch(config)# no boot system flash:c3750-ipservicesk9-mz.122-55.SE5.bin

Switch#wri
Building configuration…
[OK]
Switch#reload
Proceed with reload? [confirm]

*Mar 1 00:19:11.277: %SYS-5-RELOAD: Reload requested by console. Reload reason: Reload command
Boot Sector Filesystem (bs) installed, fsid: 2
Base ethernet MAC Address: 00:23:05:9d:de:00
Xmodem file system is available.
The password-recovery mechanism is enabled.
Initializing Flash…
flashfs[0]: 443 files, 8 directories
flashfs[0]: 0 orphaned files, 0 orphaned directories
flashfs[0]: Total bytes: 15998976
flashfs[0]: Bytes used: 15053824
flashfs[0]: Bytes available: 945152
flashfs[0]: flashfs fsck took 38 seconds.
…done Initializing Flash.
done.
Loading “flash:/c3750-ipbasek9-mz.122-55.SE1/c3750-ipbasek9-mz.122-55.SE1.bin”…@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@… [Ommitted for brevity]

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
File “flash:/c3750-ipbasek9-mz.122-55.SE1/c3750-ipbasek9-mz.122-55.SE1.bin” uncompressed and installed, entry point: 0x1000000
executing…

Restricted Rights Legend

Use, duplication, or disclosure by the Government is
subject to restrictions as set forth in subparagraph
(c) of the Commercial Computer Software – Restricted
Rights clause at FAR sec. 52.227-19 and subparagraph
(c) (1) (ii) of the Rights in Technical Data and Computer
Software clause at DFARS sec. 252.227-7013.

cisco Systems, Inc.
170 West Tasman Drive
San Jose, California 95134-1706

Cisco IOS Software, C3750 Software (C3750-IPBASEK9-M), Version 12.2(55)SE1, RELEASE SOFTWARE (fc1)
Technical Support: http://www.cisco.com/techsupport
Copyright (c) 1986-2010 by Cisco Systems, Inc.
Compiled Thu 02-Dec-10 07:46 by prod_rel_team
Image text-base: 0x01000000, data-base: 0x02D00000

Initializing flashfs…

flashfs[1]: 443 files, 8 directories
flashfs[1]: 0 orphaned files, 0 orphaned directories
flashfs[1]: Total bytes: 15998976
flashfs[1]: Bytes used: 15053824
flashfs[1]: Bytes available: 945152
flashfs[1]: flashfs fsck took 27 seconds.
flashfs[1]: Initialization complete….done Initializing flashfs.

Checking for Bootloader upgrade.. not needed
POST: CPU MIC register Tests : Begin
POST: CPU MIC register Tests : End, Status Passed

POST: PortASIC Memory Tests : Begin
POST: PortASIC Memory Tests : End, Status Passed

POST: CPU MIC interface Loopback Tests : Begin
POST: CPU MIC interface Loopback Tests : End, Status Passed

POST: PortASIC RingLoopback Tests : Begin
POST: PortASIC RingLoopback Tests : End, Status Passed

Waiting for Stack Master Election…
POST: Inline Power Controller Tests : Begin
POST: Inline Power Controller Tests : End, Status Passed

POST: PortASIC CAM Subsystem Tests : Begin
POST: PortASIC CAM Subsystem Tests : End, Status Passed

POST: No Cable found on stack port 1
POST: No Cable found on stack port 2

POST: PortASIC Stack Port Loopback Tests : Begin
POST: PortASIC Stack Port Loopback Tests : End, Status Passed

POST: PortASIC Port Loopback Tests : Begin
POST: PortASIC Port Loopback Tests : End, Status Passed

Election Complete
Switch 2 booting as Master
Waiting for Port download…Complete
This product contains cryptographic features and is subject to United
States and local country laws governing import, export, transfer and
use. Delivery of Cisco cryptographic products does not imply
third-party authority to import, export, distribute or use encryption.
Importers, exporters, distributors and users are responsible for
compliance with U.S. and local country laws. By using this product you
agree to comply with applicable laws and regulations. If you are unable
to comply with U.S. and local laws, return this product immediately.

A summary of U.S. laws governing Cisco cryptographic products may be found at:
http://www.cisco.com/wwl/export/crypto/tool/stqrg.html

If you require further assistance please contact us by sending email to
export@cisco.com.

cisco WS-C3750-24P (PowerPC405) processor (revision R0) with 131072K bytes of memory.
Processor board ID FDO1235X4KN
Last reset from power-on
1 Virtual Ethernet interface
24 FastEthernet interfaces
2 Gigabit Ethernet interfaces
The password-recovery mechanism is enabled.

512K bytes of flash-simulated non-volatile configuration memory.
Base ethernet MAC Address : 00:23:05:9D:DE:00
Motherboard assembly number : 73-9672-10
Power supply part number : 341-0029-05
Motherboard serial number : FDO123502G1
Power supply serial number : DTN122545WP
Model revision number : R0
Motherboard revision number : A0
Model number : WS-C3750-24PS-S
System serial number : FDO1235X4KN
Top Assembly Part Number : 800-25860-05
Top Assembly Revision Number : A0
Version ID : V06
CLEI Code Number : COMU410ARA
Hardware Board Revision Number : 0x01
Switch Ports Model SW Version SW Image
—— —– —– ———- ———-
* 2 26 WS-C3750-24P 12.2(55)SE1 C3750-IPBASEK9-M
Press RETURN to get started!
*Mar 1 00:01:35.319: %STACKMGR-4-SWITCH_ADDED: Switch 2 has been ADDED to the stack
*Mar 1 00:01:42.374: %LINEPROTO-5-UPDOWN: Line protocol on Interface Vlan1, changed state to down
*Mar 1 00:01:43.725: %SPANTREE-5-EXTENDED_SYSID: Extended SysId enabled for type vlan
*Mar 1 00:01:47.055: %SYS-5-CONFIG_I: Configured from memory by console
*Mar 1 00:01:47.315: %STACKMGR-5-SWITCH_READY: Switch 2 is READY
*Mar 1 00:01:47.315: %STACKMGR-4-STACK_LINK_CHANGE: Stack Port 1 Switch 2 has changed to state DOWN
*Mar 1 00:01:47.315: %STACKMGR-4-STACK_LINK_CHANGE: Stack Port 2 Switch 2 has changed to state DOWN
*Mar 1 00:01:47.709: %STACKMGR-5-MASTER_READY: Master Switch 2 is READY
*Mar 1 00:01:47.978: %SYS-5-RESTART: System restarted —
Cisco IOS Software, C3750 Software (C3750-IPBASEK9-M), Version 12.2(55)SE1, RELEASE SOFTWARE (fc1)
Technical Support: http://www.cisco.com/techsupport
Copyright (c) 1986-2010 by Cisco Systems, Inc.
Compiled Thu 02-Dec-10 07:46 by prod_rel_team
*Mar 1 00:01:50.427: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet2/0/24, changed state to up
*Mar 1 00:01:51.786: %LINK-3-UPDOWN: Interface FastEthernet2/0/24, changed state to up% Generating 1024 bit RSA keys, keys will be non-exportable…[OK]

*Mar 1 00:02:08.135: %SSH-5-ENABLED: SSH 1.99 has been enabled
*Mar 1 00:02:10.291: %PKI-6-AUTOSAVE: Running configuration saved to NVRAM
*Mar 1 00:02:19.821: %LINEPROTO-5-UPDOWN: Line protocol on Interface Vlan1, changed state to up
Switch>
Switch>en
Switch#sh flash

Directory of flash:/

2 drwx 192 Mar 1 1993 00:17:41 +00:00 c3750-ipbasek9-mz.122-55.SE1
3 -rwx 676 Mar 1 1993 00:03:56 +00:00 vlan.dat
449 -rwx 106 Mar 1 1993 00:17:42 +00:00 info
450 -rwx 1939 Mar 1 1993 00:02:13 +00:00 private-config.text
451 -rwx 3096 Mar 1 1993 00:02:13 +00:00 multiple-fs
452 -rwx 2493 Mar 1 1993 00:02:11 +00:00 config.text

15998976 bytes total (941568 bytes free)
Switch#sh ver
Cisco IOS Software, C3750 Software (C3750-IPBASEK9-M), Version 12.2(55)SE1, RELEASE SOFTWARE (fc1)
Technical Support: http://www.cisco.com/techsupport
Copyright (c) 1986-2010 by Cisco Systems, Inc.
Compiled Thu 02-Dec-10 07:46 by prod_rel_team
Image text-base: 0x01000000, data-base: 0x02D00000

ROM: Bootstrap program is C3750 boot loader
BOOTLDR: C3750 Boot Loader (C3750-HBOOT-M) Version 12.2(44)SE5, RELEASE SOFTWARE (fc1)

Switch uptime is 28 minutes
System returned to ROM by power-on
System image file is “flash:/c3750-ipbasek9-mz.122-55.SE1/c3750-ipbasek9-mz.122-55.SE1.bin”
This product contains cryptographic features and is subject to United
States and local country laws governing import, export, transfer and
use. Delivery of Cisco cryptographic products does not imply
third-party authority to import, export, distribute or use encryption.
Importers, exporters, distributors and users are responsible for
compliance with U.S. and local country laws. By using this product you
agree to comply with applicable laws and regulations. If you are unable
to comply with U.S. and local laws, return this product immediately.

A summary of U.S. laws governing Cisco cryptographic products may be found at:
http://www.cisco.com/wwl/export/crypto/tool/stqrg.html

If you require further assistance please contact us by sending email to
export@cisco.com.

cisco WS-C3750-24P (PowerPC405) processor (revision R0) with 131072K bytes of memory.
Processor board ID FDO1235X4KN
Last reset from power-on
1 Virtual Ethernet interface
48 FastEthernet interfaces
4 Gigabit Ethernet interfaces
The password-recovery mechanism is enabled.

512K bytes of flash-simulated non-volatile configuration memory.
Base ethernet MAC Address : 00:23:05:9D:DE:00
Motherboard assembly number : 73-9672-10
Power supply part number : 341-0029-05
Motherboard serial number : FDO123502G1
Power supply serial number : DTN122545WP
Model revision number : R0
Motherboard revision number : A0
Model number : WS-C3750-24PS-S
System serial number : FDO1235X4KN
Top Assembly Part Number : 800-25860-05
Top Assembly Revision Number : A0
Version ID : V06
CLEI Code Number : COMU410ARA
Hardware Board Revision Number : 0x01
Switch Ports Model SW Version SW Image
—— —– —– ———- ———-
* 2 26 WS-C3750-24P 12.2(55)SE1 C3750-IPBASEK9-M
Configuration register is 0xF

Switch#show version
Cisco IOS Software, C3750 Software (C3750-IPBASEK9-M), Version 12.2(55)SE1, RELEASE SOFTWARE (fc1)
Technical Support: http://www.cisco.com/techsupport
Copyright (c) 1986-2010 by Cisco Systems, Inc.
Compiled Thu 02-Dec-10 07:46 by prod_rel_team
Image text-base: 0x01000000, data-base: 0x02D00000

ROM: Bootstrap program is C3750 boot loader
BOOTLDR: C3750 Boot Loader (C3750-HBOOT-M) Version 12.2(44)SE5, RELEASE SOFTWARE (fc1)

Switch uptime is 28 minutes
System returned to ROM by power-on
System image file is “flash:/c3750-ipbasek9-mz.122-55.SE1/c3750-ipbasek9-mz.122-55.SE1.bin”
This product contains cryptographic features and is subject to United
States and local country laws governing import, export, transfer and
use. Delivery of Cisco cryptographic products does not imply
third-party authority to import, export, distribute or use encryption.
Importers, exporters, distributors and users are responsible for
compliance with U.S. and local country laws. By using this product you

Switch#sh flash

Directory of flash:/

2 drwx 192 Mar 1 1993 00:17:41 +00:00 c3750-ipbasek9-mz.122-55.SE1
3 -rwx 676 Mar 1 1993 00:03:56 +00:00 vlan.dat
449 -rwx 106 Mar 1 1993 00:17:42 +00:00 info
450 -rwx 1939 Mar 1 1993 00:02:13 +00:00 private-config.text
451 -rwx 3096 Mar 1 1993 00:02:13 +00:00 multiple-fs
452 -rwx 2493 Mar 1 1993 00:02:11 +00:00 config.text

15998976 bytes total (941568 bytes free)

 

Switch#dir flash:c3750-ipbasek9-mz.122-55.SE1
Directory of flash:/c3750-ipbasek9-mz.122-55.SE1/

513 drwx 4608 Mar 1 1993 01:55:17 +00:00 html
4 -rwx 12079771 Mar 1 1993 02:08:32 +00:00 c3750-ipbasek9-mz.122-55.SE1.bin
7 -rwx 681 Mar 1 1993 02:08:32 +00:00 info

32514048 bytes total (17454080 bytes free)

Cisco 3750/3850 install IOS using archive tar method

By italchemy

I have been working on Cisco 3850 and it has a new installation method called INSTALL mode which unpacks all files and save time during the book up and processing time. Since I do not have a Cisco 3850, the closest thing I can emulate this is the tar method used on older 3750 switches. My switches were running on BUNDLE mode, so had to archive tar the file to install the IOS on its seperate directory.

INSTALL method – decompress all files to the flash, similar to old tar method

BUNDLE mode – if you simply dump the IOS on the root of the flash:/ and your device is booting up from undecompressed image (.bin) file.

 

Read about 3850 INSTALL vs BUNDLE IOS upgrade and recovery process.

https://www.cisco.com/c/en/us/support/docs/switches/catalyst-3850-series-switches/117552-technote-cat3850-00.html

========

Important Command used:

show switch

switch 1 renumber 2

show flash

archive tar /xtract tftp://192.168.254.10/c3750-ipbasek9-tar.122-55.SE1.tar flash:

========

 
Switch#show switch
Switch/Stack Mac Address : 0023.059d.de00
H/W Current
Switch# Role Mac Address Priority Version State
———————————————————-
*1 Master 0023.059d.de00 10 0 Ready

Switch#conf t
Switch(config)#no switch 1 priority 14
Changing the Switch Priority of Switch Number 1 to 1
Do you want to continue?[confirm]
New Priority has been set successfully
Switch(config)#switch 1 renumber 2
WARNING: Changing the switch number may result in a
configuration change for that switch.
The interface configuration associated with the old switch
number will remain as a provisioned configuration.
Do you want to continue?[confirm]
Changing Switch Number 1 to Switch Number 2
New Switch Number will be effective after next reboot
Switch#ping 192.168.254.10
Sending 5, 100-byte ICMP Echos to 192.168.254.10, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/203/1007 ms

Switch#show flash

Directory of flash:/

2 -rwx 13006601 Mar 1 1993 03:44:48 +00:00 c3750-ipservicesk9-mz.122-55.SE5.bin
3 -rwx 676 Mar 1 1993 00:03:56 +00:00 vlan.dat
4 -rwx 1048 Mar 1 1993 00:01:44 +00:00 multiple-fs

15998976 bytes total (2988544 bytes free)
Switch#delete flash:c3750-ipservicesk9-mz.122-55.SE5.bin
Delete filename [c3750-ipservicesk9-mz.122-55.SE5.bin]?
Delete flash:c3750-ipservicesk9-mz.122-55.SE5.bin? [confirm]
Switch#$archive tar /xtract tftp://192.168.254.10/c3750-ipbasek9-tar.122-55.SE1.tar flash:
Loading c3750-ipbasek9-tar.122-55.SE1.tar from 192.168.254.10 (via Vlan1): !
c3750-ipbasek9-mz.122-55.SE1/ (directory)
c3750-ipbasek9-mz.122-55.SE1/html/ (directory)
extracting c3750-ipbasek9-mz.122-55.SE1/html/layers.js (1616 bytes)
extracting c3750-ipbasek9-mz.122-55.SE1/html/title.js (577 bytes)
… [Ommitted for brevity]
extracting c3750-ipbasek9-mz.122-55.SE1/html/images/cna_icon4.gif (1072 bytes)
extracting c3750-ipbasek9-mz.122-55.SE1/html/images/205701.gif (17278 bytes)
extracting c3750-ipbasek9-mz.122-55.SE1/c3750-ipbasek9-mz.122-55.SE1.bin (12079771 bytes)!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!OOOOOOOOOOOOOOO!OOOOOOOOOOOOOOOOOOOO!OOOOOOOOOOOOOOOOOOOO!OOOOOOOOOOO
extracting c3750-ipbasek9-mz.122-55.SE1/info (681 bytes)O
extracting info (106 bytes)
[OK – 15257600 bytes]

Switch#show flash

Directory of flash:/

2 drwx 192 Mar 1 1993 00:17:41 +00:00 c3750-ipbasek9-mz.122-55.SE1
3 -rwx 676 Mar 1 1993 00:03:56 +00:00 vlan.dat
4 -rwx 1048 Mar 1 1993 00:01:44 +00:00 multiple-fs
449 -rwx 106 Mar 1 1993 00:17:42 +00:00 info

15998976 bytes total (948224 bytes free)

 
Switch#show boot system
flash:c3750-ipservicesk9-mz.122-55.SE5.bin

Switch#conf t

Switch(config)# no boot system flash:c3750-ipservicesk9-mz.122-55.SE5.bin

Switch#wri
Building configuration…
[OK]
Switch#reload
Proceed with reload? [confirm]

*Mar 1 00:19:11.277: %SYS-5-RELOAD: Reload requested by console. Reload reason: Reload command
Boot Sector Filesystem (bs) installed, fsid: 2
Base ethernet MAC Address: 00:23:05:9d:de:00
Xmodem file system is available.
The password-recovery mechanism is enabled.
Initializing Flash…
flashfs[0]: 443 files, 8 directories
flashfs[0]: 0 orphaned files, 0 orphaned directories
flashfs[0]: Total bytes: 15998976
flashfs[0]: Bytes used: 15053824
flashfs[0]: Bytes available: 945152
flashfs[0]: flashfs fsck took 38 seconds.
…done Initializing Flash.
done.
Loading “flash:/c3750-ipbasek9-mz.122-55.SE1/c3750-ipbasek9-mz.122-55.SE1.bin”…@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@… [Ommitted for brevity]

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
File “flash:/c3750-ipbasek9-mz.122-55.SE1/c3750-ipbasek9-mz.122-55.SE1.bin” uncompressed and installed, entry point: 0x1000000
executing…

Restricted Rights Legend

Use, duplication, or disclosure by the Government is
subject to restrictions as set forth in subparagraph
(c) of the Commercial Computer Software – Restricted
Rights clause at FAR sec. 52.227-19 and subparagraph
(c) (1) (ii) of the Rights in Technical Data and Computer
Software clause at DFARS sec. 252.227-7013.

cisco Systems, Inc.
170 West Tasman Drive
San Jose, California 95134-1706

Cisco IOS Software, C3750 Software (C3750-IPBASEK9-M), Version 12.2(55)SE1, RELEASE SOFTWARE (fc1)
Technical Support: http://www.cisco.com/techsupport
Copyright (c) 1986-2010 by Cisco Systems, Inc.
Compiled Thu 02-Dec-10 07:46 by prod_rel_team
Image text-base: 0x01000000, data-base: 0x02D00000

Initializing flashfs…

flashfs[1]: 443 files, 8 directories
flashfs[1]: 0 orphaned files, 0 orphaned directories
flashfs[1]: Total bytes: 15998976
flashfs[1]: Bytes used: 15053824
flashfs[1]: Bytes available: 945152
flashfs[1]: flashfs fsck took 27 seconds.
flashfs[1]: Initialization complete….done Initializing flashfs.

Checking for Bootloader upgrade.. not needed
POST: CPU MIC register Tests : Begin
POST: CPU MIC register Tests : End, Status Passed

POST: PortASIC Memory Tests : Begin
POST: PortASIC Memory Tests : End, Status Passed

POST: CPU MIC interface Loopback Tests : Begin
POST: CPU MIC interface Loopback Tests : End, Status Passed

POST: PortASIC RingLoopback Tests : Begin
POST: PortASIC RingLoopback Tests : End, Status Passed

Waiting for Stack Master Election…
POST: Inline Power Controller Tests : Begin
POST: Inline Power Controller Tests : End, Status Passed

POST: PortASIC CAM Subsystem Tests : Begin
POST: PortASIC CAM Subsystem Tests : End, Status Passed

POST: No Cable found on stack port 1
POST: No Cable found on stack port 2

POST: PortASIC Stack Port Loopback Tests : Begin
POST: PortASIC Stack Port Loopback Tests : End, Status Passed

POST: PortASIC Port Loopback Tests : Begin
POST: PortASIC Port Loopback Tests : End, Status Passed

Election Complete
Switch 2 booting as Master
Waiting for Port download…Complete
This product contains cryptographic features and is subject to United
States and local country laws governing import, export, transfer and
use. Delivery of Cisco cryptographic products does not imply
third-party authority to import, export, distribute or use encryption.
Importers, exporters, distributors and users are responsible for
compliance with U.S. and local country laws. By using this product you
agree to comply with applicable laws and regulations. If you are unable
to comply with U.S. and local laws, return this product immediately.

A summary of U.S. laws governing Cisco cryptographic products may be found at:
http://www.cisco.com/wwl/export/crypto/tool/stqrg.html

If you require further assistance please contact us by sending email to
export@cisco.com.

cisco WS-C3750-24P (PowerPC405) processor (revision R0) with 131072K bytes of memory.
Processor board ID FDO1235X4KN
Last reset from power-on
1 Virtual Ethernet interface
24 FastEthernet interfaces
2 Gigabit Ethernet interfaces
The password-recovery mechanism is enabled.

512K bytes of flash-simulated non-volatile configuration memory.
Base ethernet MAC Address : 00:23:05:9D:DE:00
Motherboard assembly number : 73-9672-10
Power supply part number : 341-0029-05
Motherboard serial number : FDO123502G1
Power supply serial number : DTN122545WP
Model revision number : R0
Motherboard revision number : A0
Model number : WS-C3750-24PS-S
System serial number : FDO1235X4KN
Top Assembly Part Number : 800-25860-05
Top Assembly Revision Number : A0
Version ID : V06
CLEI Code Number : COMU410ARA
Hardware Board Revision Number : 0x01
Switch Ports Model SW Version SW Image
—— —– —– ———- ———-
* 2 26 WS-C3750-24P 12.2(55)SE1 C3750-IPBASEK9-M
Press RETURN to get started!
*Mar 1 00:01:35.319: %STACKMGR-4-SWITCH_ADDED: Switch 2 has been ADDED to the stack
*Mar 1 00:01:42.374: %LINEPROTO-5-UPDOWN: Line protocol on Interface Vlan1, changed state to down
*Mar 1 00:01:43.725: %SPANTREE-5-EXTENDED_SYSID: Extended SysId enabled for type vlan
*Mar 1 00:01:47.055: %SYS-5-CONFIG_I: Configured from memory by console
*Mar 1 00:01:47.315: %STACKMGR-5-SWITCH_READY: Switch 2 is READY
*Mar 1 00:01:47.315: %STACKMGR-4-STACK_LINK_CHANGE: Stack Port 1 Switch 2 has changed to state DOWN
*Mar 1 00:01:47.315: %STACKMGR-4-STACK_LINK_CHANGE: Stack Port 2 Switch 2 has changed to state DOWN
*Mar 1 00:01:47.709: %STACKMGR-5-MASTER_READY: Master Switch 2 is READY
*Mar 1 00:01:47.978: %SYS-5-RESTART: System restarted —
Cisco IOS Software, C3750 Software (C3750-IPBASEK9-M), Version 12.2(55)SE1, RELEASE SOFTWARE (fc1)
Technical Support: http://www.cisco.com/techsupport
Copyright (c) 1986-2010 by Cisco Systems, Inc.
Compiled Thu 02-Dec-10 07:46 by prod_rel_team
*Mar 1 00:01:50.427: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet2/0/24, changed state to up
*Mar 1 00:01:51.786: %LINK-3-UPDOWN: Interface FastEthernet2/0/24, changed state to up% Generating 1024 bit RSA keys, keys will be non-exportable…[OK]

*Mar 1 00:02:08.135: %SSH-5-ENABLED: SSH 1.99 has been enabled
*Mar 1 00:02:10.291: %PKI-6-AUTOSAVE: Running configuration saved to NVRAM
*Mar 1 00:02:19.821: %LINEPROTO-5-UPDOWN: Line protocol on Interface Vlan1, changed state to up
Switch>
Switch>en
Switch#sh flash

Directory of flash:/

2 drwx 192 Mar 1 1993 00:17:41 +00:00 c3750-ipbasek9-mz.122-55.SE1
3 -rwx 676 Mar 1 1993 00:03:56 +00:00 vlan.dat
449 -rwx 106 Mar 1 1993 00:17:42 +00:00 info
450 -rwx 1939 Mar 1 1993 00:02:13 +00:00 private-config.text
451 -rwx 3096 Mar 1 1993 00:02:13 +00:00 multiple-fs
452 -rwx 2493 Mar 1 1993 00:02:11 +00:00 config.text

15998976 bytes total (941568 bytes free)
Switch#sh ver
Cisco IOS Software, C3750 Software (C3750-IPBASEK9-M), Version 12.2(55)SE1, RELEASE SOFTWARE (fc1)
Technical Support: http://www.cisco.com/techsupport
Copyright (c) 1986-2010 by Cisco Systems, Inc.
Compiled Thu 02-Dec-10 07:46 by prod_rel_team
Image text-base: 0x01000000, data-base: 0x02D00000

ROM: Bootstrap program is C3750 boot loader
BOOTLDR: C3750 Boot Loader (C3750-HBOOT-M) Version 12.2(44)SE5, RELEASE SOFTWARE (fc1)

Switch uptime is 28 minutes
System returned to ROM by power-on
System image file is “flash:/c3750-ipbasek9-mz.122-55.SE1/c3750-ipbasek9-mz.122-55.SE1.bin”
This product contains cryptographic features and is subject to United
States and local country laws governing import, export, transfer and
use. Delivery of Cisco cryptographic products does not imply
third-party authority to import, export, distribute or use encryption.
Importers, exporters, distributors and users are responsible for
compliance with U.S. and local country laws. By using this product you
agree to comply with applicable laws and regulations. If you are unable
to comply with U.S. and local laws, return this product immediately.

A summary of U.S. laws governing Cisco cryptographic products may be found at:
http://www.cisco.com/wwl/export/crypto/tool/stqrg.html

If you require further assistance please contact us by sending email to
export@cisco.com.

cisco WS-C3750-24P (PowerPC405) processor (revision R0) with 131072K bytes of memory.
Processor board ID FDO1235X4KN
Last reset from power-on
1 Virtual Ethernet interface
48 FastEthernet interfaces
4 Gigabit Ethernet interfaces
The password-recovery mechanism is enabled.

512K bytes of flash-simulated non-volatile configuration memory.
Base ethernet MAC Address : 00:23:05:9D:DE:00
Motherboard assembly number : 73-9672-10
Power supply part number : 341-0029-05
Motherboard serial number : FDO123502G1
Power supply serial number : DTN122545WP
Model revision number : R0
Motherboard revision number : A0
Model number : WS-C3750-24PS-S
System serial number : FDO1235X4KN
Top Assembly Part Number : 800-25860-05
Top Assembly Revision Number : A0
Version ID : V06
CLEI Code Number : COMU410ARA
Hardware Board Revision Number : 0x01
Switch Ports Model SW Version SW Image
—— —– —– ———- ———-
* 2 26 WS-C3750-24P 12.2(55)SE1 C3750-IPBASEK9-M
Configuration register is 0xF

Switch#show version
Cisco IOS Software, C3750 Software (C3750-IPBASEK9-M), Version 12.2(55)SE1, RELEASE SOFTWARE (fc1)
Technical Support: http://www.cisco.com/techsupport
Copyright (c) 1986-2010 by Cisco Systems, Inc.
Compiled Thu 02-Dec-10 07:46 by prod_rel_team
Image text-base: 0x01000000, data-base: 0x02D00000

ROM: Bootstrap program is C3750 boot loader
BOOTLDR: C3750 Boot Loader (C3750-HBOOT-M) Version 12.2(44)SE5, RELEASE SOFTWARE (fc1)

Switch uptime is 28 minutes
System returned to ROM by power-on
System image file is “flash:/c3750-ipbasek9-mz.122-55.SE1/c3750-ipbasek9-mz.122-55.SE1.bin”
This product contains cryptographic features and is subject to United
States and local country laws governing import, export, transfer and
use. Delivery of Cisco cryptographic products does not imply
third-party authority to import, export, distribute or use encryption.
Importers, exporters, distributors and users are responsible for
compliance with U.S. and local country laws. By using this product you

Switch#sh flash

Directory of flash:/

2 drwx 192 Mar 1 1993 00:17:41 +00:00 c3750-ipbasek9-mz.122-55.SE1
3 -rwx 676 Mar 1 1993 00:03:56 +00:00 vlan.dat
449 -rwx 106 Mar 1 1993 00:17:42 +00:00 info
450 -rwx 1939 Mar 1 1993 00:02:13 +00:00 private-config.text
451 -rwx 3096 Mar 1 1993 00:02:13 +00:00 multiple-fs
452 -rwx 2493 Mar 1 1993 00:02:11 +00:00 config.text

15998976 bytes total (941568 bytes free)

 

Switch#dir flash:c3750-ipbasek9-mz.122-55.SE1
Directory of flash:/c3750-ipbasek9-mz.122-55.SE1/

513 drwx 4608 Mar 1 1993 01:55:17 +00:00 html
4 -rwx 12079771 Mar 1 1993 02:08:32 +00:00 c3750-ipbasek9-mz.122-55.SE1.bin
7 -rwx 681 Mar 1 1993 02:08:32 +00:00 info

32514048 bytes total (17454080 bytes free)

❌