HTTP/2 è il nuovo standard per le comunicazioni Web che sostituirà presto il vetusto HTTP 1.1, introducendo consistenti miglioramenti che dovrebbero portare ad una maggiore velocità e sicurezza per quello che riguarda il Web. Al Black Hat 2016 a Las Vegas, la conferenza dove annualmente si discutono i problemi di sicurezza, i ricercatori hanno esposto però quelli che sembrano difetti potenziali del nuovo protocollo. Tom Van Goethem e Mathy Vanhoef hanno descritto una vulnerabilità che chiamano HEIST (HTTP Encrypted Information can be Stolen through TCP-windows… assegnare i nomi è sempre complicato!), un attacco che consente di determinare la dimensione esatta delle risposte TCP e rende più semplici vecchie modalità di attacco perchè i protocolli SSL/TLS non fanno nulla per oscurare la lunghezza dei pacchetti.

“Concretamente, questo significa che attacchi basati sulla compressone come il CRIME o il BREACH possono essere eseguiti direttamente nel browser, da qualsiasi sito Web o script malevolo e senza che sia necessaria una posizione man-in-the-middle. Inoltre, noi dimostriamo anche come i nostri attacchi basati sulla dimensione [dei pacchetti] possano essere usati per ottenere informazioni sensibili da vittime ignare, conducendo abusi di servizi su siti Web popolari”, hanno dichiarato.

I ricercatori sono stati inoltre in grado di aumentare gli effetti dannosi degli attacchi utilizzando in modo malevolo funzionalità del nuovo protocollo HTTP/2, in particolare la sua capacità di usare una connessione TCP unica per lanciare richieste in parallelo. Mitigare questi attacchi sarebbe molto difficile ed una, se non l’unica, delle poche misure possibili è quella di disabilitare i cookie di terze parti.

Contemporaneamente, Imperva ha presentato un report che descrive vettori di attacco nel protocollo HTTP/2 che aprono vulnerabilità in cinque popolari implementazioni server del protocollo stesso, incluso IIS di Microsoft, Apache, Nginx, Jetty e nghttpd.

“Nello studio abbiamo rilevato vulnerabilità in quasi tutte le componenti del nuovo protocollo HTTP/2”, affermano. “I quattro diversi vettori d’attacco che abbiamo scoperto sono Slow Read, HPACK (compressione), Dependency DoS e Stream abuse. Nei cinque server che abbiamo messo alla prova, tutti erano vulnerabili almeno ad uno dei vettori d’attacco, con Slow Read che era decisamente quello prevalente”.

Sebbene siano stati verificate solo cinque implementazioni, Imperva ha concluso che probabilmente le vulnerabilità esistono anche in altri server HTTP/2. L’azienda ha comunque lavorato con i produttori dei server per assicurarsi che le vulnerabilità fossero state corrette prima della pubblicazione del report.

Da qualche tempo PHP ha iniziato a rilasciare anche delle build per Windows a 64bit, probabilmente in previsione del lancio della prima versione 64bit non sperimentale per la versione 7 di PHP. Sono attualmente disponibili le versioni x64 sia di PHP 5.5 che 5.6 oltre che ovviamente dell’ultima nata. Il framework dispone anche della corrispondente versione a 64 bit per la OpCache distribuita con i file compilati per Windows ma la sorpresa è che invece il modulo WinCache che Microsoft ha sviluppato qualche anno fa per migliorare le prestazioni di PHP (e che spesso viene considerato uno dei migliori moduli di accelerazione disponibili) non ha invece distribuzioni a 64bit ufficiali.

Certamente quelle versioni di PHP non hanno molto seguito in ambiente Windows e questo non ha spinto Microsoft a fornire versioni diverse del proprio acceleratore ma ora che ci sono delle distribuzioni ufficiali a 64bit per PHP 5.5 e 5.6 sarebbe comunque positivo poter integrare la OpCache di Zend e WinCache di Microsoft. Da notare che per PHP 7 la versione x64 di WinCache è prevista ed in fase di testing.

Per fortuna sul Web qualcuno ha pensato di compilare a 64bit il modulo WinCache e renderlo disponibile ! Questo sito Web ha delle build a 64bit per PHP 5.5 e 5.6 fino alla versione 1.3.7.4 di WinCache, forse non l’ultima build ma comunque molto recenti visto che l’ultima ha data 30/3/2015.

La domanda quindi è: funzionano ? Ovviamente non le abbiamo provate tutte ma possiamo dire che The Server-Side Technology usa ora PHP 5.6 x64 con la versione di WinCache 1.3.7.4 disponibile sul sito che abbiamo indicato. Abbiamo avuto grandi risultati con PHP7 ma alcune parti del nostro sito non erano al 100% compatibili e siamo ritornati a PHP 5.6, mantenendo però la versione a 64bit come base. Se avete quindi bisogno della versione 64bit del modulo WinCache, per adesso possiamo consigliare di provare quelle compilazioni: non sembrano esserci problemi particolari di compatibilità. Del resto, dovrebbero essere solo compilazioni a 64bit dei file originali….

A few days ago Microsoft released ASP.NET 5 beta8, the first feature-complete version of its flagship Web framework. A lot of expectations come with this new version, both because Microsoft decided to change ASP.NET down to its basis and because this one will be the first multi-platform release for the technology, allowing developers to run their Web or console applications on Windows, Linux and Mac OS X. However, the new version will also be the first one designed from the ground up for the cloud era and thus adopting all methodologies, technologies and conventions that emerged in past few years. As we detailed in a past article (sorry: Italian language only this time!), ASP.NET 5 will also change the way ASP.NET will be hosted on Windows because it will run through the famous HTTPPlatformHandler module that enabled Azure to run basically any runtime, including Java, Python, RoR and more. Later, that module has been channeled down to partners and Windows Azure Pack incorporated it in UR7.

You might be running your website or application on Windows Azure Pack and, if you do, I do really hope that you’re hosting with us at VaiSulWeb since we also have free accounts for you to try ASP.NET 5. However, even if you’re hosting at another service provider, you might be wondering if you will be able to run ASP.NET 5 starting from beta8, since this version switches to HTTPPlatformHandler. Up until beta7, hosting with Azure Pack was very easy: you only needed to publish your project to a folder and then upload that package to your WAP account. Everything was working fine since the very first second.

Spoiler: scroll down for a quick solution

There’s a quick solution waiting for you at the end of this article. If you’re only interested in understanding how you can run ASP.NET 5 from beta8 using WAP, just skip this lengthy explanation and run to the end. This article will be used to as an handy excuse to showcase some nice features that Windows Azure Pack provide its users and that our company provides its customers. We will use such features to understand what’s going on with beta8 and then provide a quick solution to host it on WAP.

Publishing your beta8 to your WAP account : Redmond we have a problem…

So you just started a new project based on ASP.NET 5 beta8 in Visual Studio 2015 or you just created a template project to check how things would shape up. Quick and easy. Now you would like to upload that project to your Web hosting account to check if your provider is compatible with the technology. So you just export your project…

Publishing your project to file system

… publishing to file system, the same way you did up to beta7. Then, after that operation completes, you upload your project on your WAP accounts via FTP or WebDeploy. Compilation time, just a few seconds, and then… uh ?

It seems that something went wrong since no shiny MVC homepage appears in your [...]

Con un post su GitHub,  Damian Edwards ha annunciato che la nuova release di ASP.NET, la versione 5, non verrà più eseguita da IIS come ISAPI ma attraverso il modulo HTTPPlatformHandler che per l’occasione verrà aggiornato con alcune modifiche e reso disponibile anche per Windows Server 2008R2, la versione minima per eseguire ASP.NET 5. La modifica sarà disponibile già con la beta8 del software e quindi al prossimo aggiornamento previsto per il 5 Ottobre 2015.

ASP.NET ed IIS

A prima vista questa modifica potrebbe sembrare ininfluente ma segna un cambiamento piuttosto importante se si considera che sin dalla sua introduzione con IIS 6 e Windows Server 2003, ASP.NET è stata eseguita da IIS come ISAPI, la configurazione che garantiva le prestazioni migliori sulla piattaforma. Lo stesso avveniva ed avviene per altre tecnologie come ASP classico mentre storicamente altri framework o estensioni provenienti dal mondo Unix usavano invece una tecnologia meno sofisticata a cui si fa riferimento in generale come CGI.

Le perplessità potrebbero sorgere proprio perché da sempre l’esecuzione ISAPI è considerata la più efficiente e quella capace di fornire prestazioni di molto più elevate sulla piattaforma Windows Server, soprattutto perché la creazione di nuovi processi è in effetti una operazione onerosa sui sistemi Windows, molto più di quanto lo sia sui sistemi Unix.

In realtà sin da Windows Server 2003 Microsoft ha affinato il supporto per le tecnologie CGI, in particolare per garantire la compatibilità con framework molto popolari come PHP. La tecnologia FastCGI è in effetti l’antesignana del modulo HTTPPlatformHandler e, sebbene con FastCGI la piattaforma Windows Server abbia efficacemente ottenuto l’esecuzione di framework come PHP con prestazioni pari o addirittura superiori a quelle dei sistemi Unix, fino a poco tempo fa era considerato impossibile che Microsoft decidesse di passare ad una modalità di esecuzione diversa per le proprie tecnologie.

HTTPPlatformHandler : l’evoluzione della specie

La notizia non può che significare che Microsoft ha ormai ottenuto una parità di performance tra l’esecuzione ISAPI e quella CGI e la chiave è senza dubbio il modulo HTTPPlatformHandler. Anticipando le perplessità di qualcuno, Edwards aggiunge che Microsoft si aspetta una differenza di prestazioni tra le due modalità solo per applicazioni triviali come una Hello World, cioè piccole applicazioni che fungono più da esempio che da reali implementazioni. Per tutti gli altri casi, probabilmente Microsoft crede di raggiungere prestazioni uguali o anche maggiori a quelle ottenibili con la tecnologia ISAPI. Certamente così facendo ottiene una flessibilità notevolmente maggiore, soprattutto in un contesto nel quale ASP.NET è diventato open-source ed in teoria qualsiasi utente potrebbe compilare la propria versione della tecnologia.

Il modulo HTTPPlatformHandler è l’evoluzione di quello FastCGI che ha consentito a Windows Server di diventare una piattaforma ideale anche per PHP a partire dalla versione 2003 e da IIS 6. FastCGI risolve il problema dell’onerosità della creazione di nuovi processi con l’attivazione di una singola istanza che verrà usata in modo efficace da IIS per gestire un numero variabile di richieste, isolandole da quelle degli altri siti Web ma gestendole sempre con un processo unico. Di tanto in tanto, in modo configurabile, [...]