L'implementazione request-response non è attualmente in grado di gestire il controllo di sicurezza sui servizi che richiedono una connessione back-channel. Per esempio, un client FTP implementa la richiesta dir e get, creando un socket TCP, mandando un messaggio al server remoto chiedendo di avere come risposta il risultato attraverso la porta aperta a tale scopo (porta random che quindi sarà differente da collegamento a collegamento) e aspettando su di essa la risposta. La classica implementazione request-response blocca la connessione attraverso questa porta. Il problema del back channel sorge in differenti forme quando un utente all'interno del firewall cerca di lanciare un client X-window da un host esterno e di farlo apparire sul proprio monitor (logicamente esterno al firewall). Per connettersi, il client esterno deve stabilire una connessione TCP all'X-server interno al firewall, ma la politica request-reresponseponse non lo permette. Si potrebbe lasciare passare questa connessione attraverso il firewall e far affidamento sul X-server di rigettare le connessioni non autorizzate, purtroppo questo meccanismo non è applicabile su tutte le macchine. Sarebbe impensabile implementare tale sistema di autentificazione su tutti i potenziali client, inoltre senza un unico e sicuro meccanismo di autentificazione, sarebbe sicuramente facile saltare l'autentificazione del server.
Attualmente quando si vuole implementare un meccanismo che permetta connessioni arbitrarie che richiedono un X-server si può usare un proxy. Il proxy alloca semplicemente un nuovo display su un bastion-host e la richiesta all'X-server proveniente dall'esterno viene forwardata su tale bastion che a sua volta ha il compito di verificare l'autenticità ed i relativi permessi del client esterno ed eventualemte permettere l'X-window. Logicamente questa gestione attraverso il bastion host dovrebbe essere una soluzione temporanea in attesa di nuove implementazioni di sicurezza che riescano a gestire le richieste di back-channel.